Short version: the incident metrics that matter most are MTTD (how fast you detect), MTTA (how fast someone acknowledges), MTTR (how fast you recover), and MTBF (how long between failures). They sit on a single timeline, and detection is at the very front of it — every minute you don't know about an outage is added directly to your time-to-recovery.
The four metrics
- MTTD — Mean Time To Detect. The average time from when an incident starts to when your system notices. This is the metric monitoring directly controls.
- MTTA — Mean Time To Acknowledge. The average time from alert fired to a human acknowledging it. On-call schedules and escalation policies drive this down.
- MTTR — Mean Time To Recovery (or Repair/Resolve). The average time from detection to service restored. The headline reliability metric, and the one leadership usually asks about.
- MTBF — Mean Time Between Failures. The average healthy interval between incidents — a measure of how often things break, not how fast you fix them.
Atlassian's incident-management handbook catalogues these and several siblings in its guide to common incident metrics; the four above are the ones most teams should track first.
They form a timeline
A single incident runs: failure starts → detected (MTTD) → acknowledged (MTTA) → recovered (MTTR) → … → next failure (MTBF). The crucial property is that these spans add up. If detection takes five minutes because you poll every five minutes, that five minutes is baked into your total time-to-recovery, no matter how fast your team moves afterward. You can have the best runbook in the world and still post a slow MTTR because the clock started late.
The formulas, with worked examples
Each of these is a mean — total time divided by a count — over some set of incidents.
MTTR. Sum the downtime across incidents, divide by the number of incidents.
Three incidents this month caused 30, 45, and 15 minutes of downtime. MTTR = (30 + 45 + 15) ÷ 3 = 30 minutes.
MTTD. Sum the detection times (start → detected), divide by the count.
If those same incidents took 5, 8, and 2 minutes to detect: MTTD = (5 + 8 + 2) ÷ 3 = 5 minutes.
MTTA. Sum the acknowledgement times (alert fired → acked), divide by the count.
Pages were acked after 3, 1, and 2 minutes: MTTA = (3 + 1 + 2) ÷ 3 = 2 minutes.
MTBF. Take the total operational (healthy) time in a period and divide by the number of failures.
Over a 30-day month (43,200 minutes) you had 3 incidents totaling 90 minutes of downtime. Uptime = 43,200 − 90 = 43,110 minutes. MTBF = 43,110 ÷ 3 = 14,370 minutes, about 10 days between failures.
Put MTTD and MTTR together and the leverage of detection becomes obvious. In the example above, MTTD is 5 of the 30 minutes of MTTR — one sixth of every incident's lifespan is spent simply not knowing.
Detection is the cheapest minute to win
Most teams pour effort into the response side — runbooks, on-call rotations, faster rollbacks — and those matter. But the single easiest place to shave minutes off MTTR is detection, because it's pure infrastructure rather than human coordination. Going from 5-minute polling to second-level checks removes up to ~5 minutes of detection lag from every incident, before your team does anything at all. No process change, no training, no heroics — just a finer instrument.
That same logic is why false positives are dangerous. If fast polling pages people for blips that aren't real outages, MTTA quietly rises: responders stop trusting alerts and hesitate before acknowledging. Confirming outages with multi-location quorum and a consecutive-failure threshold keeps detection fast and trustworthy, so the speed you gain at the front of the timeline isn't given back at the acknowledgement step.
A caveat: treat MTTR as a trend, not a grade
It's worth being honest about MTTR's limits. Incident durations are highly variable and right-skewed — a handful of nasty incidents can dominate the mean — so an MTTR computed over a small sample is noisy, and chasing it as a precise target can mislead. Some practitioners argue the mean hides more than it reveals.
The practical response is not to drop the metric but to use it well:
- Look at the trend over time, not a single month's number.
- Report medians and percentiles alongside the mean, so one outlier doesn't swamp the picture.
- Segment by severity, so a 10-second blip and a multi-hour outage aren't averaged together.
Used this way, these metrics point you at where the time goes — and the timeline tells you the time almost always starts going at detection.
How to improve each one
- Lower MTTD: check more often and from multiple locations; alert on the SLIs users actually feel.
- Lower MTTA: clear on-call schedules, sensible escalation, and a single channel where alerts land.
- Lower MTTR: runbooks, practiced rollbacks, and incident management with a shared timeline so everyone has the same context.
- Raise MTBF: fix root causes via postmortems instead of just restarting and moving on.
Where to go next
- Connect these to targets with SLA vs SLO vs SLI and error budgets.
- Drive MTTA down with a fair on-call rotation.
- See what slow detection costs in dollars with the downtime cost calculator.