MTTR, mean time to recovery, is the average time it takes to restore a service after an incident begins. You calculate it by adding up the total downtime across incidents and dividing by the number of incidents. If five outages cost 150 minutes of downtime in total, your MTTR is 30 minutes. It is one of the clearest signals of how well a team detects, responds to, and fixes problems, and it is a headline DORA metric for that reason.
Uptime tells you how often you are up. MTTR tells you how fast you recover when you are not. The two together describe reliability far better than either alone, because a team can have decent uptime and still be one bad, slow-to-fix incident away from a customer walking. Lowering MTTR is often the fastest way to improve the experience of an outage, since you cannot always prevent incidents but you can almost always shorten them.
How do you calculate MTTR?
The formula is simple: total downtime divided by the number of incidents over a period.
MTTR = total downtime ÷ number of incidents
Example: 4 incidents in a month, with downtimes of 10, 20, 45 and 5 minutes. Total is 80 minutes. MTTR is 80 ÷ 4 = 20 minutes.
The subtlety is where you start and stop the clock. Most teams measure recovery from the moment the incident begins to the moment service is fully restored, which folds detection time, response time and repair time into one number. That is useful as a headline, but when you want to improve it, you break it into the stages below so you can see which one is costing you.
MTTR vs MTTD, MTTA and MTBF
The MTT family of metrics gets muddled constantly because the letters are so close. Each measures a different slice of an incident's life.
| Metric | Measures | Clock runs from |
|---|---|---|
| MTTD (detect) | How long until you notice | Incident starts to detection |
| MTTA (acknowledge) | How long until someone responds | Alert fires to acknowledgement |
| MTTR (recovery) | How long until service is restored | Incident starts to full recovery |
| MTBF (between failures) | How reliable the system is | Recovery to the next failure |
MTTR sometimes stands for mean time to repair rather than recovery, and the two differ slightly: repair is the hands-on fixing time, while recovery includes detection and response. Whichever definition you use, pick one and stay consistent, because the value is in the trend over time, not the absolute number.
How to reduce MTTR
Because MTTR bundles several stages, you shrink it by attacking whichever stage is slowest for you.
- Detect faster. The clock is already running before anyone knows. Fast, frequent monitoring closes the gap between an outage starting and your team learning about it. A check every 30 seconds catches a problem in a fraction of the time a five-minute interval does. For jobs that run on a schedule rather than serving traffic, heartbeat monitoring is what closes the same detection gap.
- Cut the noise so real alerts land. If detection is buried under false pages, response is slow. Confirming a failure before paging means the alert that fires is one people act on.
- Route to the right person. An alert that reaches someone who cannot fix it wastes the most expensive minutes. Clear on-call and escalation get the incident to a capable responder fast, which is the whole point of a well-designed on-call rotation.
- Write runbooks. The repair stage shrinks when the responder is not improvising. A short runbook per alert turns a 40-minute investigation into a 10-minute fix; our runbook template gives you the structure to start from.
- Find the answer quickly. A lot of MTTR is spent hunting: which change shipped, where the runbook lives, who owns this service. Teams that can surface the right answer from across their internal tools in seconds spend far less of an incident simply looking for information.
alertping
The cheapest minutes to cut are the ones before you know
AlertPing checks every 30 seconds from two regions and confirms an outage from the second before it pages you, so detection is measured in seconds. The faster you know, the lower your MTTR. SMS on every plan.
What is a good MTTR?
There is no universal target, because MTTR depends on system complexity, incident severity and what "restored" means for your product. A team running a simple stateless web app might recover in minutes; a team untangling a data corruption issue across services might take hours for the same severity. The number that matters is your own trend: is this quarter's MTTR lower than last quarter's? A falling MTTR means your detection, response and repair are improving together, which is exactly what the metric is for.
Compare it against your reliability goals rather than someone else's benchmark. If you are holding an uptime target, your error budget and your MTTR move together: every minute you shave off recovery is a minute of budget you keep. For the uptime side of that equation, see what counts as a good uptime percentage.
The practical takeaway: MTTR is a mirror. A high or rising number is not a failure of one heroic responder, it is a signal that one of detection, response or repair is slow. Break the number into stages, find the slow one, and fix that. Most teams discover the cheapest win is detection, because the clock starts the moment things break, not the moment they notice, and closing that gap is simply a matter of getting website down alerts that fire in seconds rather than after the first customer email.