MTTR, or mean time to recovery, is the average elapsed time from failure to restored service, measured from the start of a failure to the full restoration of service, calculated over a set of incidents in a given period. In reliability engineering for servers, MTTR measures how quickly a team and its systems bounce back, while MTBF measures how often failures happen in the first place.
Together the two metrics determine availability: a system that fails rarely but takes days to recover can be less available than one that fails more often but recovers in minutes. This is why modern operations practice treats fast recovery as a design goal, not only an operational hope.
How MTTR is calculated
MTTR is the total recovery time divided by the number of incidents in the measurement window. If a service had four incidents in a quarter lasting 20, 45, 10 and 85 minutes, the total is 160 minutes and the MTTR is 40 minutes.
The result depends entirely on where the clock starts and stops. Recovery can be measured from the moment the fault began, from the first alert or from the moment an engineer acknowledged it, and it can end when a workaround restores users or when the root cause is fixed. Teams must define these points in writing, or MTTR values cannot be compared over time.
| Segment | Starts at | Ends at | Main lever |
|---|---|---|---|
| Time to detect | Fault begins | Alert fires | Monitoring and alerting quality |
| Time to acknowledge | Alert fires | Responder engages | On-call process |
| Time to diagnose | Responder engages | Cause identified | Logs, metrics, runbooks |
| Time to repair | Cause identified | Fix or failover applied | Automation and tooling |
| Time to verify | Fix applied | Service confirmed normal | Health checks and tests |
Because MTTR is an arithmetic mean, one very long outage can dominate it. Many teams therefore report the median and the 90th percentile of recovery times alongside the mean to show whether a change reflects a trend or a single extreme event.
The four meanings of the MTTR acronym
The letters MTTR are used for several related but different metrics, and confusing them is a frequent source of misleading reports. In server reliability and incident management, recovery is the most common meaning, but hardware maintenance contracts usually mean repair.
| Expansion | Clock stops when | Typical use |
|---|---|---|
| Mean time to recovery | Service is restored for users | Operations, SRE, DORA metrics |
| Mean time to repair | Faulty component is repaired | Hardware maintenance, field service |
| Mean time to resolve | Root cause is fixed for good | Problem management, ITSM |
| Mean time to respond | Team begins active response | Security operations, on-call |
Any MTTR figure in a report or contract should state which expansion and which start and end points it uses. A vendor promising a four-hour repair time for a failed disk is describing something very different from a service team reporting a twelve-minute recovery time.
MTTR, MTBF, RTO and availability
MTTR links directly to availability through the classic formula availability = MTBF / (MTBF + MTTR). Halving MTTR raises availability as much as doubling MTBF, and in software systems it is usually far cheaper to achieve.
| Metric | What it measures | Nature |
|---|---|---|
| MTTR | Average time to restore service | Observed, backward-looking |
| MTBF | Average time between failures | Observed or predicted |
| RTO | Maximum acceptable recovery time | Target set in advance |
| RPO | Maximum acceptable data loss | Target set in advance |
| Uptime | Share of time service is available | Outcome of MTBF and MTTR |
A key distinction is that RTO is a promise and MTTR is a measurement. If the measured MTTR for a class of incidents approaches or exceeds the agreed RTO, the recovery design is not good enough, even if most incidents end well.
Practical ways to reduce MTTR
Reducing MTTR means attacking each segment of recovery time. The largest gains usually come from faster detection and from automated failover, which removes human reaction time from the critical path.
| Measure | Segment improved | Effect |
|---|---|---|
| Symptom-based alerting | Detection | Alerts on user impact, not only on causes |
| Runbooks and playbooks | Diagnosis and repair | Responders follow tested steps |
| Automated failover | Repair | Hot standby or active-active takes over in seconds |
| Fast rollback | Repair | Bad deployments are reverted quickly |
| Chaos engineering drills | All segments | Teams rehearse recovery before real incidents |
Architecture matters as much as process. Systems built from small, replaceable components with redundancy and no single point of failure can often recover by replacing an instance instead of repairing it, which turns a long investigation into a short automatic replacement.
Pitfalls in measuring and using MTTR
MTTR is easy to compute and easy to misuse. The most common mistake is comparing figures with different definitions, for example across teams that start the clock at different points.
- Small sample sizes make MTTR swing wildly from one quarter to the next.
- Excluding partial outages or degraded performance makes recovery look better than users experienced.
- Closing incidents early to improve the metric hides unresolved problems.
- Mixing severities lets many trivial incidents mask a few long, serious ones.
- Optimizing MTTR alone can encourage quick restarts that never address the root cause.
Used well, MTTR is a trend indicator for recovery capability, reviewed together with incident postmortems. Used as a target for individuals, it tends to distort reporting rather than improve reliability.
In plain words
MTTR answers a simple question: when something breaks, how long until it works again? It is the average of those waiting times over many incidents.
Think of a city bus service. Buses will break down now and then. What passengers care about is how fast a replacement bus arrives. A short MTTR means problems are brief, even if they still happen. Lowering it is often easier than preventing every failure.
A real-world example
An online retailer tracks incidents on its checkout service. Over six months it records ten incidents, and the mean time to recovery is 52 minutes. Postmortems show that about 30 minutes of each incident pass before anyone notices, because alerts watch CPU usage rather than failed orders.
The team adds an alert on the checkout error rate, writes runbooks for the three most frequent failure types and configures automatic database failover to a hot standby replica. They also enable one-click rollback in the deployment pipeline, since half of the incidents followed a release.
In the next six months the service has a similar number of incidents, but the MTTR falls to about 11 minutes. The failure rate barely changed; the availability gain comes almost entirely from faster recovery, which the team reports together with the median and worst-case recovery times.