Reports
How the team is actually responding — detection, acknowledgement, resolution.
Analytics → Reports measures the response rather than the systems.
What is measured
| Metric | Question |
|---|---|
| Time to detect | How long between the problem starting and anything noticing |
| Time to acknowledge | How long before a human claimed it |
| Time to resolve | How long until it was over |
| Alert volume | How many, by severity, by service, by team |
| Escalation depth | How often the page reached step 2 or beyond |
| Out-of-hours rate | How much of this lands outside working hours |
Escalation and response
Analytics → Escalation & Response breaks these down by team and by hour.
Two patterns worth looking for:
Frequent escalation past step 1. Either the primary is overloaded, or the paging channel is not reaching them. Both are fixable and both are invisible without this number.
A high out-of-hours rate for one team. Usually one noisy rule that happens to fire at night, not a genuinely worse system. Pair with Alert intelligence.
Time to detect is the important one
Time to resolve gets the attention. Time to detect is where the leverage is: it applies to every future incident, and improving it is usually cheaper than improving anything else.
If your time to detect is frequently "when a customer told us", that is a monitoring gap and it belongs in the post-mortem action items.
Reading these honestly
Mean time to resolve is an average over things that were not the same. One three-day incident and forty five-minute ones produce a number that describes neither.
Look at the distribution and at the outliers. The outliers are where the learning is.
Related
- Scheduled reports — send these regularly
- SLOs — the target the numbers are measured against
Where this behaviour lives: frontend/src/app/analytics/, frontend/src/app/analytics/escalation/. If the code and this page disagree, the code is right — please fix the page.
Part of Analytics and cost — Dashboards, SLOs, reports and what the infrastructure costs.