Incident metrics report: six numbers, one page, twenty minutes
Ask a room how incident response is going and you will get vibes: "feels like a rough month," "I think things got better after the new alerts," "wasn't that the same payment bug as June?" Nobody can act on vibes, and the loudest anecdote in the room wins by default. The monthly incident metrics report exists to end that argument — six numbers, compiled in about twenty minutes from tables the team already keeps, each one pointing at a decision. The cap matters as much as the count: a metrics report that runs to a deck protects nobody, because nobody reads page two.
This is the template: the four response numbers (MTTD, MTTA, MTTR, recurrence rate) and the rule that they are medians per severity, never a blended mean; the two health numbers (action-closure rate, cadence-kept %) that tell you whether the system is improving between incidents; where every timestamp comes from; the bands that separate a good month from a lucky one; the do-not-measure list; and the one-page layout that ends in a decision, not a shrug.
1. The argument the report ends
Every ops review drifts toward the same fight: one person is sure response got worse this month, another is sure the new monitoring fixed things, and both are arguing from memory. Six numbers settle it in ninety seconds — not because numbers are sacred, but because each one is dated and sourced. The rule that keeps the report alive is that every number ends in a decision. If a month produces six numbers and zero decisions, the report has become the deck it was invented to replace.
2. The four response numbers
Four numbers, each with a formula, a source, and a rule:
| Number | Formula | Where the timestamps come from |
|---|---|---|
| MTTD — time to detect | median minutes from impact start to detection | the incident timeline table (impact-start row vs detected row); provider dashboards; a first customer report counts as detection only if monitoring missed it — log that miss, it is your next detection purchase |
| MTTA — time to acknowledge | median minutes from alert fired to a human engaged (pager ack) | on-call ack timestamps |
| MTTR — time to restore | median minutes from detection to service restored | the timeline table; "restored" means customers can transact, not "fix deployed" |
| Recurrence rate | % of incidents whose contributing factor matches one already logged in a prior post-mortem | the blameless review log — the only number that measures whether the team is actually learning |
The rule that keeps all four honest: medians, per severity level. A mean blended across severities is a number that lies — one six-hour SEV1 and twenty five-minute SEV4s average into a fiction. Compute the median for each level the severity matrix defines; report the medians side by side. With fewer than five incidents at a level in the month, report the individual incidents instead of a median — a median of three is decoration.
3. The two health numbers
The response numbers say how the machines did. The health numbers say whether the system around them is improving:
| Number | Formula | Source |
|---|---|---|
| Action-closure rate | % of post-mortem actions shipped by their due date | the five-action table each blameless review produces (the cap is what makes it countable) |
| Cadence-kept % | % of incidents where every promised update went out inside its window | the incident communication timeline — each update row carries a promised next-update time; either it was kept or it was not |
Six numbers total. A seventh is a slide, and slides are how this report dies.
4. Where the timestamps come from
The metrics are downstream of two tables the team should already keep: the incident timeline table (written during incidents, not reconstructed afterwards) and the post-mortem action table. If the timeline table is not being filled in the moment, stop here and fix that first — reconstructed numbers are fiction with a confident font. This is also the report's first quality gate: the percentage of incidents with a complete timeline table is itself a metric (section 9). If it is under 100%, mark the month's report provisional and say why on the page.
5. What good looks like: bands, not targets
Targets invite gaming; bands invite diagnosis. Read each month's number against its band, and treat a move between bands as the decision trigger:
| Number | Healthy band | What the bad band means |
|---|---|---|
| MTTD, SEV1 | under 10 minutes — monitoring covered the path that broke | over 30 minutes means detection-by-customer: fund detection first (the 40% slice of the IR budget), do not buy anything else yet |
| MTTA, paged incidents | under 5 minutes | over 15 is a rota or staffing problem, not a tooling one — no dashboard fixes it |
| MTTR, SEV2 | under 60 minutes is the small-team bar | any SEV1 over 4 hours generates one detection item and one rollback item, whatever the root cause |
| Recurrence | top-3 causes do not repeat within the quarter | same cause twice means the action did not ship, or shipped and did not work — reopen it |
| Action-closure | about 70% by due date is honest | 100% every month means the actions were written to be sandbagged; tighten the due dates |
| Cadence-kept | 90% or better | each miss gets a line and a cause — the missed update at 2am is a rota finding, not a scolding |
6. What not to measure
Small teams drown in dashboards by measuring things that can only be improved by lying. The do-not-measure list:
- Uptime as a vanity number — five nines of a service nobody depends on is a certificate, not a metric; the SLO definition page covers the honest version, with an error budget attached.
- Per-person response speed league tables — nothing kills a blameless review faster than a scoreboard. The moment MTTA becomes a contest, acks get gamed and the data becomes theatre.
- Incidents per person — it measures who reports honestly, not who breaks things.
- Ticket counts inflated by reclassification — if the number improves when someone recategorizes, it is not a metric.
- Anything that can only improve by redefining "incident," "restore," or "due date." If a definition change would move the number, fix the definition first, then re-baseline — never compare across the change.
7. The one-page layout
The report is one page, and every block earns its place:
- Header: month, total incidents, count by severity level.
- The six numbers with a trend arrow against last month (↑↓→) and the band each sits in. A number without its band is trivia.
- Three lines, maximum: what moved and why — each line names the change that moved it (the new alert, the rollback runbook, the rota gap). A number that moved with no named cause is a mystery, not a win.
- The action table: every open post-mortem action with owner and due date, the overdue count in bold. The overdue count is the most honest number on the page.
- One question at the bottom: what do we stop or start because of this page? The report ends when the question has an answer, not when the page is printed.
8. Worked example: twelve-person payments SaaS, six incidents in August
The team had argued for a quarter about whether response was "getting better." The first report took twenty minutes to compile from the timeline tables they were already keeping:
| Number | July | August | Why |
|---|---|---|---|
| MTTD, SEV1–2 | 31 min | 9 min | queue-depth alert shipped after the July gateway outage (the detection line item from the IR budget) |
| MTTA, paged | 6 min | 6 min | flat — Sunday rota gap, one engineer covering two services; became September's action |
| MTTR, SEV2 | 71 min | 44 min | rollback runbook written after the June deploy incident |
| Recurrence | 33% | 17% | the config-change factor got a pre-deploy checklist; two of twelve incidents still touched it |
| Action-closure | 3/5 | 4/5 | the fifth shipped four days late; the delay was the finding, not the failure |
| Cadence-kept | 4/6 | 5/6 | the miss was a 2am SEV3 with one on-call; single-writer rule needs the rota fix too |
Three decisions came off the page: fund a Sunday rota slot (MTTA will not move otherwise), add the queue-depth alert to the vendor-onboarding checklist so new integrations inherit it, and stop the weekly ops sync — the numbers showed it had surfaced nothing the report did not. The meeting that used to run on vibes now runs twenty minutes with the page as the only agenda.
9. Metrics that keep the report honest
- Timeline completeness: % of incidents with a full timeline table. Under 100%, the report prints "provisional" — the input, not the math, is the gap.
- Compiled within three business days of month end. A report that arrives on the 20th is a history lesson; by day three it is still a decision.
- One decision per report, logged. Six numbers, zero decisions, two months running — either the numbers are fine (say so and shrink the report) or the report is decoration (kill it and fix the timeline table).
Where this fits
The severity matrix is what makes the medians meaningful — the severity matrix template defines the levels the numbers are grouped into. The incident communication timeline is the source of both the cadence-kept % and half the timestamps; the blameless post-incident review produces the action table that closure rate counts, and its contributing-factors log is where recurrence comes from. When a number refuses to move, the incident response budget is how you buy the fix — detection first. And if the uptime number is doing all the talking, the SLA/SLO definition template replaces it with an error budget that has opinions.
From the HIVE80lab kit
- The First 30 Minutes — free incident quick-start
- Ops Starter Kit — full incident-response kit for small teams — $14
- Ops Starter Kit Vol. 2 — advanced incident response & communications — $27
- Ops Mega Bundle — all 5 kits in one download — $29
- Custom Incident Runbook — done-for-you, built from your estate, 48h — $249