Glossary
Mean time to recovery (MTTR)
MTTR is the average time from a problem being detected to service being restored, across every incident in a period.
Also called MTTR, Mean time to restore, Mean time to repair, Mean time to resolve, Mean time to respond.
The MTTR formula is MTTR = total recovery time ÷ number of incidents. Five incidents totalling 150 minutes of recovery time give an MTTR of 150 ÷ 5 = 30 minutes. The mean hides the spread. Take a month with four incidents that took 12, 18, 30 and 240 minutes to recover: MTTR is (12 + 18 + 30 + 240) / 4 = 75 minutes. The median of the same four is 24 minutes, which is why the two numbers belong side by side — one long outage drags the mean far away from what a typical incident felt like.
Mean time to recovery is the average duration from detection to service being restored. It is the headline incident metric almost everywhere, and it is worth being precise about which clock it uses: some teams measure from the problem starting, some from detection, some from acknowledgement, and the same organisation can produce very different numbers depending on the choice. The letters are also overloaded. Restore is used interchangeably with recovery, so mean time to restore is the same clock, while repair, resolve and respond all appear behind MTTR and mean subtly different things.
The mean is the weakest part. A quarter with fifty two-minute blips and one nine-hour outage has a flattering average and one very unhappy customer base. The distribution is what carries the information: the median says what a normal incident is like, and the worst few say what the organisation is actually capable of when something is genuinely hard.
What reduces it is rarely faster typing. It is knowing sooner, having a runbook so diagnosis is not improvisation, and above all being able to roll back quickly — most incidents are caused by a change, and the fastest recovery is usually undoing one rather than fixing forward. Recovery and root cause are separate jobs, and conflating them is the most common way a two-minute rollback becomes a two-hour investigation with customers waiting.
| Metric | Clock runs from | What shortens it |
|---|---|---|
| MTTD (mean time to detect) | The problem starting until someone knows about it | A shorter check interval and monitors on what actually breaks |
| MTTA (mean time to acknowledge) | The alert firing until a person takes ownership | A clear on-call rota and escalation that pages the next person |
| MTTR (mean time to recovery) | Detection until service is restored for users | Runbooks and a fast rollback |
| MTBF (mean time between failures) | One failure ending until the next one starts | Fixing root causes rather than symptoms |
Questions
What is MTTR?
MTTR stands for mean time to recovery: the average time from a problem being detected to service being restored, across every incident in a period. Many teams say mean time to restore for the same clock.
What does MTTR stand for?
Most often mean time to recovery, which many teams also call mean time to restore. The same letters are also used for mean time to repair, mean time to resolve and mean time to respond, which start or stop the clock at different moments. Say which one a number uses before comparing it with anyone else's.
What are the four meanings of MTTR?
Repair, recovery (or restore), respond and resolve. Repair covers the hands-on fix, recovery and restore run until service is back for users, and resolve runs until the incident is fully closed. Respond is used for the response side, and sources disagree on where it ends: some stop at the first response, others at the fix. Sources also draw the line between repair and resolve differently, which is why a number means little until its clock is named.
How do you calculate MTTR?
Add up the recovery time of every incident in the period and divide by the number of incidents. Four incidents of 12, 18, 30 and 240 minutes give (12 + 18 + 30 + 240) / 4 = 75 minutes.
What is the difference between MTTR and MTTD?
MTTD measures how long a problem went unnoticed. MTTR measures how long it took to fix once it was noticed. Added together they are roughly how long users were affected.
What is a good MTTR?
There is no universal number, because teams measure different clocks and different incidents. Compare the trend against your own past quarters, and watch the median and the worst incident alongside the mean.
Does MTTR include the time to detect a problem?
Under mean time to recovery it usually starts at detection, so detection time is reported separately as MTTD. Some teams start the clock when the problem began instead. Either is fine as long as it is stated and kept consistent.
In Uptimely
Uptimely timestamps each incident state change on its own timeline, so time to acknowledge and time to resolve are read from records rather than reconstructed. Resolution messages state how long the incident ran.
Uptimely records when each incident was declared, acknowledged and resolved, so your MTTR comes from the timeline instead of memory.
Start monitoring free →Related terms
Part of the Uptimely monitoring glossary — plain definitions of the vocabulary uptime monitoring, incident response and status pages are discussed in. Something here read wrong to you? Email support@getuptimely.com.