Guide
Time to restore service (MTTR)
Time to restore service is how long it takes to recover when a change causes a failure in production — from the moment the problem starts affecting users to the moment service is restored. It is the fourth DORA metric, and arguably the one with the most leverage, because it determines how expensive a mistake is and therefore how boldly an organisation can ship.
Why recovery time is the leverage point
An organisation that can recover in fifteen minutes and one that takes two days will make completely different decisions about risk, regardless of what either says about its appetite for it. Slow recovery makes every release frightening, which produces larger batches, longer approval chains and — through exactly the mechanism DORA describes — more failures.
This is why recovery time tends to be the most productive of the four to work on first. Improving it makes everything downstream cheaper, and unlike deployment frequency it is not constrained by anyone else’s release calendar.
Measuring it without arguing about it
The clock starts when users are affected, not when someone noticed. That distinction matters enormously: for many organisations the detection gap is the largest part of the total, and a metric that starts at detection quietly hides the observability problem that is actually costing them.
It stops when service is restored, not when the root cause is understood or a permanent fix is deployed. A rollback that restores service in four minutes is a four-minute recovery even if the proper fix ships a week later.
And as with lead time, use the median. Recovery time distributions are dominated by a small number of very bad days, and a mean will describe those days rather than your typical one.
What actually reduces it
In order of how reliably they help: a rollback path that has been exercised recently, monitoring that alerts on user-visible symptoms rather than on infrastructure metrics, deployments small enough that the cause is obvious, and feature flags that let a change be turned off without a deploy.
Postmortems help too, but indirectly and slowly. The fast wins are almost always in detection and reversal.
Where this measure goes wrong
Each of these produces a number that looks reasonable and is not.
Starting the clock at detection
This hides the detection gap, which is frequently the largest component and the easiest to improve.
Stopping the clock at root cause
Service restored is the measure. A rollback that works is a recovery.
Using the mean
One catastrophic incident will dominate the mean and describe a day that is not representative of anything.
Excluding incidents that were "not really our fault"
Users experienced the outage. Filtering by attribution produces a number that is comfortable and useless.
Frequently asked questions
What does MTTR stand for?
Mean time to restore, or mean time to recovery — the terms are used interchangeably, and confusingly it is also sometimes expanded to mean time to repair, which is a different thing. DORA’s own current phrasing is "failed deployment recovery time", which avoids the ambiguity.
What is a good MTTR?
Under one hour is elite by DORA’s banding, under one day is high. Context matters: a batch system with a nightly window has a structural floor that a web service does not.
Should we measure mean or median?
Median, in almost every case. Recovery times are heavily skewed by rare severe incidents. If you report the mean, report the median alongside it — the gap between them is itself informative.
See time to restore service for your own teams
Pacia computes this from your repositories and issue tracker, banded and trended, with a drill-down to the work behind every figure.