What is MTTR (mean time to restore)?
Updated
MTTR — mean time to restore — is the average time it takes to restore service after a production failure or incident. It is one of the four DORA metrics and measures how quickly a team recovers, serving as a proxy for operational resilience and effective incident response rather than for how often failures occur.
The acronym is ambiguous across the industry: MTTR is variously read as mean time to restore, recover, repair, respond, or resolve. In the DORA context specifically it means time to restore service — how long from a failure being detected in production to service being usable again.
What MTTR measures and why the acronym is ambiguous
In the DORA model, MTTR is the stability counterpart to the speed metrics: it asks not how fast you ship but how fast you recover when a change breaks something. A team that deploys often will occasionally cause incidents; what separates a resilient team is that it detects and restores service quickly rather than staying down. This reframes reliability around recovery time instead of trying to prevent every failure.
MTTR is one of the most overloaded acronyms in operations, so it pays to be explicit about which one you mean. The variants measure different clocks, and mixing them produces numbers that cannot be compared.
| Acronym | Reads as | What it measures |
|---|---|---|
| MTTR (DORA) | Mean time to restore | Failure in production to service usable again |
| MTTR | Mean time to recover | Often used interchangeably with restore |
| MTTR | Mean time to repair | Time actively spent fixing the underlying fault |
| MTTA | Mean time to acknowledge | Alert fired to someone taking ownership |
| MTTD | Mean time to detect | Failure occurring to it being detected |
| MTBF | Mean time between failures | Average uptime between successive failures |
How to calculate MTTR
The basic calculation is total downtime across incidents divided by the number of incidents over a period. If five incidents in a quarter took a combined ten hours to restore, MTTR is two hours. The mean is simple, but it is sensitive to outliers — one multi-day incident can dominate the average — so many teams also track the median and the distribution alongside the mean.
The harder part is defining the clock boundaries consistently. Decide up front when the timer starts (failure occurs, alert fires, or incident is declared) and when it stops (service restored versus root cause fixed). MTTR usually stops at service restored, even if a permanent fix lands later. Whatever you choose, apply it uniformly, because MTTR is only meaningful as a trend against itself.
What good looks like, and common pitfalls
DORA groups teams into performance tiers rather than prescribing a single universal target, and the highest performers restore service dramatically faster than the lowest. Rather than chase a specific number copied from a report, treat MTTR as a trend line for your own system: falling MTTR alongside stable or improving change failure rate is the healthy signal.
The main pitfalls are definitional and behavioral. Inconsistent start and stop points make MTTR uncomparable across teams. Averaging over too few incidents makes it noisy. And because MTTR looks good when incidents are short, it can be gamed by closing incidents early or by classifying real degradations as non-incidents — which is why MTTR should always be read next to change failure rate and the underlying incident count, never alone.
Frequently asked questions
How is MTTR calculated?
Sum the total time to restore service across all incidents in a period, then divide by the number of incidents. For example, five incidents totaling ten hours of downtime give an MTTR of two hours. Because the mean is skewed by outliers, teams often report the median and distribution alongside it.
What does MTTR stand for?
It depends on context. In the DORA metrics, MTTR means mean time to restore (service). Elsewhere the same acronym is read as mean time to recover, repair, respond, or resolve — each measuring a slightly different clock. Related acronyms include MTTA (acknowledge), MTTD (detect), and MTBF (between failures).
What is a good MTTR?
There is no single universal target. DORA sorts teams into performance tiers, and the strongest teams restore service far faster than the weakest, but the meaningful comparison is against your own trend. A falling MTTR paired with a stable or improving change failure rate is the healthy pattern to watch for.
Published by ShipReady Metrics, an evidence-based technology and compliance intelligence platform. This guide is educational and vendor-neutral.