MTTR (Mean Time to Recovery)
MTTR is the average time from when an incident starts until service is restored to an acceptable level — a core reliability metric for measuring how fast your team recovers from outages.
On this page
MTTR — mean time to recovery (sometimes called mean time to repair or resolve) — is the average elapsed time from the start of an incident until your service is restored to a level your customers and stakeholders accept.
Teams track MTTR because it answers a practical question: when something breaks, how long are we down? It complements detection speed MTTD (mean time to detect) and reliability targets SLOs (service level objectives) to give a fuller picture of incident response effectiveness.
Why it matters
A high MTTR usually signals gaps in coordination, tooling, or preparedness — not just slow engineers. Long recovery times mean more customer impact, more revenue at risk, and more on-call stress. Improving MTTR often means better runbooks, clearer roles, and faster escalation — the same foundations covered in our What Is Incident Management? guide.
| Signal | What a rising MTTR might mean |
|---|---|
| Triage delays | Alerts not routed to the right owner quickly |
| Coordination gaps | No incident commander, duplicated work |
| Missing runbooks | Responders rediscover fixes under pressure |
| Weak handoffs | Context lost between shifts or teams |
Example
Your API returns 503 errors from 14:00 to 14:47 before the on-call rolls back a bad deploy. If you define “incident start” as first customer-visible error and “recovery” as error rate back under your SLO threshold, MTTR for that event is 47 minutes. Over a quarter, you average those durations across incidents to get team-level MTTR.
Common mistakes
- Measuring recovery as “deploy finished” instead of when customers are actually unblocked.
- Mixing severity levels — a Sev-1 outage and a minor degradation should not be averaged without context.
- Optimizing MTTR alone — cutting recovery time while detection stays slow MTTD (mean time to detect) still leaves a large blind spot.
- Gaming the metric by declaring incidents resolved before impact truly ends.
Use MTTR as a trend line for improvement conversations, not a single number to punish individuals. Pair it with timelines, severity tags, and follow-up work so the metric drives better process — not shortcuts.