The Lifecycle report shows where incident time actually goes, stage by stage. Instead of one headline number, it breaks every incident into five stages so you can see whether time is lost detecting problems, acknowledging them, confirming them, fixing them, or watching the fix hold.
🧭 The five stages
Every incident is split into five stages, measured in whole minutes:
Detect – from Incident Start to Creation. How long the disruption ran before it was raised in Phoenix.
Ack – from Creation to the first time the incident moved into Assessing. How quickly someone took ownership.
Verify – from the first time the incident moved into Assessing to the first time it moved into Fixing. How quickly the team confirmed it was a real incident.
Fix – from the first time the incident moved into Fixing to the Incident End. Time spent fixing until the fix was deployed. If a fix does not hold and the team returns to Fixing, that rework counts here too.
Monitor – from the Incident End to when the incident was Resolved. Time spent watching the fix before closing out.
The five stages always add up to the incident's full journey, from Incident Start to Resolved. If an incident never entered a stage (for example, it was resolved directly from Assessing and never moved to Fixing), that stage is excluded from the numbers rather than counted as zero.
🗂️ Which incidents are included
The page includes incidents that were resolved in the selected period. An incident that is still open does not appear until it is resolved.
Monthly columns group each incident by the month it was resolved, in your Jira site's timezone.
Canceled incidents are always excluded.
📊 What is on the page
Stage cards – the average time in each stage across the period, with the change from the previous period.
The average incident, start to finish – a ribbon showing the average incident's journey. Segment widths are scaled for readability; the numbers on each segment are the true durations.
Average time in each stage by product – your top five products by total incident time, with the rest grouped as Other.
Stage durations, month by month – a heatmap where darker cells are slower. Blank cells had no incidents in that stage that month.
Typical vs outliers – a box plot per stage. The box holds the middle half of incidents, the bar is the median, whiskers stretch to the fastest and slowest, and the diamond is the average.
Slowest incidents – the top five incidents for the period, with their severity, product, and a per-stage breakdown. Use the "Slowest by" filter to rank by a single stage.
💡 Reading the numbers well
Percentiles are real incidents. The 90th percentile is an actual incident's duration: 90 percent of incidents took that long or less. Phoenix never shows calculated in-between values.
Zero is not missing. A zero means the stage happened within a minute. A stage the incident never entered is left out entirely.
Slowest incidents rules differ by view. In a stage view, incidents with zero recorded time in that stage are left out. The Overall view includes any incident whose total recorded time is above zero.
Timestamps drive everything. Confirming Incident Start and Incident End during the RCA keeps these numbers honest, exactly as with the headline metrics.
For the definitions behind Time to Detect, MTTA, MTTR, and Uptime, see 📊 Metrics & Definitions.