Phoenix Incidents tracks a handful of timing metrics for every incident, and rolls them up across incidents in reporting. This page defines each one and the timestamps behind it.
🕒 The timestamps behind the metrics
Every metric is built from a few key moments in an incident:
Incident Start – when the disruption actually began. You can set this, or it defaults to the creation time, and you can correct it later.
Creation – when the incident was raised in Phoenix.
Incident End – when service was restored. If you use the Monitoring phase, it is set automatically when the incident moves to Monitoring. Otherwise you set it when you resolve the incident, and in Slack it defaults to the current time. Either way, you can adjust it later, just like Incident Start.
Resolved – when the incident was resolved in Jira, after any monitoring and close-out.
Status transitions – the moments the incident first moves to Assessing (acknowledged) and Fixing (verified).
📈 Per-incident metrics
Each incident shows the time it spent in each of the five lifecycle stages:
Detect Time – from Incident Start to Creation. How long the disruption ran before it was raised in Phoenix.
Ack Time – from Creation to the first time the incident moved into Assessing. How quickly someone took ownership.
Verify Time – 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 Time – from the first time the incident moved into Fixing to the Incident End. Time spent fixing until the fix was deployed.
Monitor Time – from the Incident End to when the incident was Resolved. Time spent watching the fix before closing out.
The five stages add up to the incident's full journey, from Incident Start to Resolved. The 🔄 Lifecycle report breaks these same five stages down across all of your incidents.
📊 Reporting roll-ups
In reporting, these are averaged across the incidents in the period you select:
Mean Time to Ack (MTTA) – the average Ack Time. Canceled and brand-new incidents are left out.
Mean Time to Recovery (MTTR) – the average time from Incident Start to Incident End, shown in hours. The headline measure of how long disruptions last. Only incidents that have both an Incident Start and an Incident End are counted, and canceled incidents are excluded.
Uptime – for each month, the share of time your products were up. Phoenix treats each incident's Incident Start to Incident End as downtime, merges any overlaps, and divides the remaining time by the total time in the month. Canceled incidents do not count.
💡 Why accurate timestamps matter
These metrics are only as good as the timestamps behind them. Most incidents actually began before the ticket was raised, so it is worth confirming the Incident Start and Incident End during the RCA. An accurate Incident Start gives you a truer Detect Time and recovery number, and a more reliable uptime figure.