MTTR (mean time to recovery, repair, respond or resolve) is the average time it takes to restore a system after a failure, calculated as total recovery time divided by the number of incidents. Together with MTTD, MTTA and MTBF it is one of the core metrics for measuring incident response and reliability.
Key takeaways
- MTTR has four common meanings (repair, recovery, respond, resolve). Define which one you use before comparing numbers.
- Formula: MTTR = total downtime or incident duration / number of incidents. Example: 180 minutes over 4 incidents gives an MTTR of 45 minutes.
- Break MTTR into phases (detect, acknowledge, diagnose, mitigate) to see where time is really lost. Diagnosis usually dominates.
- Incident durations are heavily skewed, so track the median and p90 alongside the mean, and never use MTTR as an individual performance target.
What is MTTR?
MTTR is the mean time it takes to get a failed system working again. It is the most widely used incident metric in IT operations and site reliability engineering because it answers a question every engineering leader asks: when something breaks, how long do users suffer? The basic formula is simple:
MTTR = sum of incident durations / number of incidents
If your team handled four production incidents last month lasting 30, 45, 90 and 15 minutes, the total is 180 minutes and the MTTR is 180 / 4 = 45 minutes.
The complication is that the "R" is ambiguous. Different teams, vendors and frameworks mean different things, and the differences matter when you compare numbers or set goals.
The four meanings of MTTR
| Metric | Measures | Starts | Ends |
|---|---|---|---|
| Mean time to repair | Hands-on fix time | Repair work begins | Component is fixed |
| Mean time to recovery (restore) | User-facing outage duration | Failure begins | Service is restored for users |
| Mean time to respond | Speed of reaction | Alert fires | Responder starts working (often equals MTTA plus triage) |
| Mean time to resolve | Full lifecycle | Failure begins | Root cause fixed and follow-ups done |
For software services, mean time to recovery is usually the most meaningful, because it tracks how long users are affected. Recovery often happens through mitigation, such as a rollback, a feature flag or a failover, long before the underlying bug is repaired. The DORA research program uses this framing: its stability metric, now called failed deployment recovery time (previously time to restore service), measures how quickly a team recovers from a change that caused a failure in production.
MTTD, MTTA, MTTR and MTBF on the incident timeline
MTTR is easiest to improve once you break an incident into phases. Each phase has its own metric:
- Failure starts. Users begin to be affected.
- Detection (MTTD, mean time to detect). Time from failure start until monitoring or a human notices it.
- Acknowledgement (MTTA, mean time to acknowledge). Time from the alert until an on-call engineer accepts it.
- Diagnosis. Time to understand what is broken and why. This phase is rarely tracked separately, but it is usually the longest.
- Mitigation and recovery. Rollback, failover, scaling or a hotfix restores service. This marks the end of time to recovery.
- Resolution. The underlying cause is fixed and postmortem actions are completed.
MTBF (mean time between failures) sits outside the incident: it measures the average operating time between one failure and the next, so it describes how often things break rather than how quickly you recover. A related metric, MTTF (mean time to failure), is used for components that are replaced rather than repaired, such as disks.
| Metric | Formula | What it tells you |
|---|---|---|
| MTTD | Sum of (detected − started) / incidents | Quality of monitoring and alerting |
| MTTA | Sum of (acknowledged − alerted) / incidents | On-call health and alert routing |
| MTTR (recovery) | Sum of (recovered − started) / incidents | Total user impact per incident |
| MTBF | Total operating time / number of failures | How often failures occur |
Worked example: from MTTR to availability
Take a 30-day month (720 hours) with the four incidents above, totalling 3 hours of user-facing downtime.
- MTTR = 180 min / 4 = 45 min (0.75 h)
- MTBF = (720 h − 3 h) / 4 = 179.25 h
- Availability = MTBF / (MTBF + MTTR) = 179.25 / 180 = 99.58%
The availability formula shows the two levers of reliability: fail less often (raise MTBF) or recover faster (lower MTTR). For complex distributed systems, where some failure is inevitable, recovering faster is usually the cheaper lever. Halving MTTR in this example would raise availability to about 99.79% without preventing a single incident. This is also why SLOs and MTTR fit together: every minute shaved off recovery is error budget you keep.
Why MTTR can mislead
MTTR is useful, but it is a blunt instrument. Know its limits before you report it to leadership:
- Skewed distributions. Incident durations follow a long-tail distribution: many short incidents and a few very long ones. A single eight-hour outage can double the monthly mean. Analyses of public incident data, such as the VOID report, have shown that the mean is a poor summary of such data. Report the median and p90 alongside the mean.
- Small samples. With five incidents a quarter, month-to-month changes are mostly noise. Look at trends over longer periods.
- Inconsistent start times. If "start" sometimes means first alert and sometimes first user impact, numbers are not comparable. Use telemetry to reconstruct the real start time.
- Goodhart's law. If MTTR becomes a target, teams may close incidents early, split them or stop declaring small ones. Never tie MTTR to individual performance reviews.
- Severity mixing. Averaging a minor degradation with a full outage hides both. Segment MTTR by severity and by service.
How to measure MTTR in practice
Reliable MTTR numbers depend less on the formula than on consistent data. A practical approach:
- Define what an incident is. Agree on severity levels and on which events are declared as incidents, for example any SLO burn rate page or any customer-visible degradation above a threshold.
- Take timestamps from telemetry, not from chat. The start of impact is when the SLI started degrading, not when someone opened a ticket. Detection is the first alert, acknowledgement is the on-call acceptance, recovery is when the SLI returned to normal.
- Record the phases separately. Store started, detected, acknowledged, mitigated and resolved for every incident.
- Report distributions. Show count, median, p90 and mean per severity and per service, over a quarter or longer.
A small example shows why phases matter:
| Incident | Detect | Acknowledge | Diagnose | Mitigate | Total |
|---|---|---|---|---|---|
| A | 4 min | 3 min | 18 min | 5 min | 30 min |
| B | 12 min | 2 min | 26 min | 5 min | 45 min |
| C | 6 min | 9 min | 65 min | 10 min | 90 min |
| D | 2 min | 1 min | 8 min | 4 min | 15 min |
Here diagnosis accounts for 117 of 180 minutes, about 65% of the total. Faster paging would barely move MTTR; better correlation and context would.
How to reduce MTTR
Improvements come from attacking each phase of the timeline separately.
Detect faster
Alert on symptoms users feel (SLO burn rate, error rate, latency) rather than on causes like CPU. Use anomaly detection for metrics without static thresholds, and synthetic checks for critical journeys so you detect failures even when traffic is low.
Acknowledge faster
Route alerts to the owning team using a service catalog, deduplicate and group related alerts into one incident, and keep on-call rotations sustainable. Alert fatigue directly increases MTTA.
Diagnose faster
This is where most time goes. Correlate metrics, logs and traces through shared context such as trace IDs and resource attributes, and keep a live topology so responders can see upstream and downstream dependencies. Overlay deployments and configuration changes on every chart: a large share of incidents is triggered by a change, so "what changed?" is often the fastest question to answer.
Recover faster
Make mitigation cheap: one-click rollbacks, feature flags, automated failover and runbooks as code. Practise them in game days so they work under pressure.
Learn from every incident
Blameless postmortems with tracked action items raise MTBF over time and keep the same failure from costing you twice.
How Obseria helps reduce MTTR
Obseria shortens each phase of the incident timeline. Burn rate alerts and anomaly detection on OpenTelemetry metrics, logs and traces reduce detection time; correlated alerts are grouped into a single problem and routed to the owning team. For diagnosis, Obseria TopoGraph shows the affected services and infrastructure in context, deployment tracking highlights recent changes, and Obseria Intelligence runs an agentic root-cause investigation that presents a chain of evidence instead of a pile of dashboards. Automation workflows can then trigger rollbacks or runbooks, and incident timelines are recorded automatically so MTTD, MTTA and MTTR are measured from telemetry rather than from memory.