On this page3 sections
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.