Definition
MTTR (Mean Time to Recovery, also called Mean Time to Repair or Mean Time to Restore) is the average time it takes to restore a service to normal operation after a failure. It is calculated as total downtime divided by the number of incidents in a given period.
MTTR = Total downtime ÷ Number of incidents
MTTR is one of the most important reliability metrics because it directly determines how much of your error budget an incident consumes. A 2-hour MTTR on a 99.9% SLO consumes 14× more error budget than a 10-minute MTTR for the same underlying failure.
What counts as recovery?
Recovery is typically measured from the moment an incident is declared to the moment service is restored to its SLO-compliant state. Some teams measure from first alert; others from when a user first experiences impact. Define your measurement point explicitly — inconsistent definitions make MTTR comparisons meaningless.
Recovery does not mean root cause is identified or fixed permanently. MTTR measures restoration speed, not problem resolution. A service restored via rollback has recovered even if the underlying bug is still open.
MTTR vs MTTF vs MTBF
| Metric | Measures | Formula | Goal |
|---|---|---|---|
| MTTR | Recovery speed | Downtime ÷ Incidents | Lower is better |
| MTTF | Time until failure | Uptime ÷ Incidents | Higher is better |
| MTBF | Full failure cycle | MTTF + MTTR | Higher is better |
MTTR and availability
MTTR is one of two levers that determine availability. The other is MTTF (how often you fail). The relationship: Availability = MTTF ÷ (MTTF + MTTR)
This means you can improve availability either by failing less often (higher MTTF) or by recovering faster (lower MTTR). In practice, reducing MTTR is often more achievable in the short term than eliminating failures entirely.
The four phases of MTTR
MTTR is the sum of four sequential phases. Improving any phase improves overall MTTR:
- Time to detect: How long before the incident is noticed. Driven by alerting quality and monitoring coverage.
- Time to diagnose: How long to identify the root cause or the impacted component. Driven by observability quality — metrics, logs, and traces.
- Time to remediate: How long to apply the fix or workaround. Driven by runbook quality, deployment pipeline speed, and rollback capability.
- Time to verify: How long to confirm service is restored. Driven by monitoring and health check coverage.
MTTR benchmarks
| DORA Band | MTTR target |
|---|---|
| Elite | Less than 1 hour |
| High | Less than 1 day |
| Medium | Less than 1 week |
| Low | More than 1 week |
How to improve MTTR
Improve detection: Reduce alert latency with lower evaluation intervals. Use symptom-based alerting (user-visible impact) rather than cause-based alerting (internal metrics). See What is Observability? for the observability foundation.
Improve diagnosis: Invest in structured logging, distributed tracing, and service dependency maps. High-quality runbooks that capture known failure patterns dramatically reduce diagnosis time.
Improve remediation: Automated rollback on failed health checks, fast deployment pipelines for hotfixes, and pre-tested runbooks. The best remediation is one that does not require human judgment at 3am.
Improve verification: Automated smoke tests and synthetic monitoring that confirm user-visible functionality is restored before closing the incident.
Use the MTTR Calculator to compute your current MTTR and implied availability from incident data.