Incidents Reviewed
MTTR, MTTD and MTBF
In this guide, MTTR (mean time to recover) is the average time from the start of impact to full recovery, MTTD (mean time to detect) the average time from the start of impact until an alert or a person notices, and MTBF (mean time between failures) the average uptime between failures; MTBF and MTTR give long-run, time-based availability = MTBF ÷ (MTBF + MTTR). The metrics are easy to compute and hard to interpret: MTTR has at least four meanings, and incident durations vary so much that the average moves even when nothing has changed.
On this page
The metrics
| Metric | Clock starts | Clock stops | Tells you about |
|---|---|---|---|
| MTTDmean time to detect | Impact begins | An alert or a person notices | Monitoring coverage |
| MTTAmean time to acknowledge | Alert fires or problem is reported | A responder acknowledges | Paging and on-call response |
| MTTMmean time to mitigate | Impact begins | Severe user impact stops | How long users are badly affected |
| MTTRmean time to recover | Impact begins | Service is fully back to normal | Outage length |
| MTBFmean time between failures | Service restored | Next failure begins | How often a repairable system fails |
| MTTFmean time to failure | Unit enters service | Unit fails | Lifetime of parts that are replaced, not repaired |
Which MTTR?
The R is commonly read four ways. These are typical boundaries, but organisations and tools draw them differently:
- Repair: the original maintenance meaning, the hands-on time to fix a failed component once work starts.
- Recover or restore: from the start of impact until the service works normally again. This is the meaning used in Davidovič’s report and in this guide; the first edition of the SRE book (2016) called its equivalent mean time to repair.
- Respond: in one convention, from the alert until someone starts working on it, close to MTTA. Others use it for alert to full recovery.
- Resolve: until the incident is closed, which may include fixing the underlying cause days later. The second edition of the SRE book (2026) reads MTTR this way and pairs it with mean time to mitigation (MTTM), until user impact is stopped or reduced enough to end the emergency.
A respond-MTTR of 5 minutes and a resolve-MTTR of 3 days can describe the same incidents. When you report one, write down the start and stop events, which incidents count (for example SEV1 and SEV2 only), and where the timestamps come from. Without that, comparisons between teams or tools are meaningless.
DORA’s software delivery research also used “mean time to recover” until 2023, when it renamed the metric failed deployment recovery time and limited it to failures caused by changes, excluding external causes such as a data centre outage.
MTBF, MTTR and availability
If MTBF is the mean uptime between failures and MTTR the mean downtime per failure, long-run availability is:
availability = MTBF ÷ (MTBF + MTTR)
This models one service alternating between fully up and fully down, with downtime that never overlaps. It gives time-based availability, not a request-success SLI, and it treats partial degradation as either up or down.
Some sources measure MTBF from the start of one failure to the start of the next, which includes the repair time. Then availability = (MTBF − MTTR) ÷ MTBF. Check which convention a figure uses before plugging it in.
The formula hides the shape of the failures. These three patterns all give 99.9% availability over 30 days, the same 43m 12s of complete outage:
| Failures | MTTR | MTBF | Availability |
|---|---|---|---|
| 1 | 43m 12s | 29d 23h 17m | 99.9% |
| 6 | 7m 12s | 4d 23h 53m | 99.9% |
| 30 | 1m 26s | 23h 58m 34s | 99.9% |
Users experience these very differently. One 43m 12s outage may break a checkout flow for everyone at once; thirty 1m 26s blips may be absorbed by client retries, or may mean a daily failure that erodes trust. The engineering response differs too: the first calls for faster recovery, the last for fewer failures. Neither MTTR nor MTBF alone says which situation you are in.
MTBF for hardware
An MTBF rating of 1,000,000 hours does not mean an individual drive will last 114 years. The figure describes a large population during its service life: at a constant failure rate it means about 0.87% of drives fail each year. Real hardware also fails more often when new and when worn out, so treat vendor MTBF as a rough annual failure rate, and prefer failure rates measured on your own fleet.
Why incident averages mislead
Incident durations are heavily skewed: most incidents end quickly and a few run for hours or days. Take twelve illustrative incidents, eleven between 4m and 1h 10m and one of 8h:
- Mean of all twelve: 59m 40s.
- Mean without the longest: 21m 27s. One incident makes the mean 2.8 times larger.
- Median of all twelve: 16m, which hides the 8h incident entirely.
Google’s report Incident Metrics in SRE tested this with incident data from three companies and from Google. For each of three companies it repeatedly drew two equally sized random samples from that company’s incident durations, with a combined size equal to its incident count for 2019, and shortened every incident in one sample by exactly 10%. MTTR still came out worse for the shortened sample in 38%, 40% and 20% of the runs for companies A, B and C. When nothing was shortened, company A’s MTTR still appeared to improve by half an hour or more in 19% of runs. The report found the same problem with the median, and concluded that MTTx metrics are poorly suited to judging trends, evaluating a process or tool, or describing overall reliability. The cause is the combination of high variance and few incidents, not poor data.
MTTR has other blind spots:
- It ignores frequency. Twice as many incidents of the same lengths leave MTTR unchanged while reliability is clearly worse.
- It ignores impact. A total outage and a degraded admin page count the same per minute.
- It is easy to game. Declaring recovery early, splitting one incident into several, or not opening incidents for long low-grade problems all improve it.
The first edition of the SRE book called MTTR the most relevant measure of emergency response, and reported that playbooks give roughly a 3× improvement over improvising. The second edition drops both claims: it says averages of time to resolve or mitigate mislead, because they hide the spread and because different incidents have very different expected timelines, and it suggests looking at how responders coordinate instead. Larger effects are easier to detect, but whether a change can be told apart from sampling variation still depends on how many incidents you have and how their durations are spread.
What to measure instead
- Error budget spent. If the question is “are we getting more reliable?”, a user-centred SLI, assessed against its SLO, measures the failures users experience, so frequency, duration and, for request-based SLIs, the share of users affected all count. A change in error budget spent still does not by itself prove a trend or that an intervention worked.
- The step you changed. If you improved alerting, look at detection time for the incidents the change affects; if you introduced a runbook, look at the incidents it covers. Including every other step in the average hides the effect.
- Individual incidents. Read the long ones in postmortems. A handful of reviewed incidents says more about response than a quarterly average.
- The cost of coordination. How many people and teams joined, how long new responders took to get up to speed, how often responders were interrupted for status updates, and how many channels and tools the response used. Patterns here point at process and tooling fixes.
- Distributions, with counts. If you chart durations, show every incident or a histogram, alongside how many there were, rather than one number.
If you report MTTx anyway
Dashboards and audits often require an MTTR. To keep it from misleading:
- Name the metric fully, for example “mean time to recover, impact start to full recovery”.
- State which incidents count, by severity and service.
- Report the incident count, median and longest next to the mean, and link to the incident list.
- Don’t set MTTR targets for teams or compare teams by it. Targets invite the gaming above, and the number moves at random.
- Don’t confuse it with an RTO, which is a limit for every disruption rather than an average over past ones.
Sources: Štěpán Davidovič, Incident Metrics in SRE (Google and O’Reilly, 2021); Google, Site Reliability Engineering, 1st ed., ch. 1 “Introduction” (MTTF, MTTR and playbooks); Site Reliability Engineering, 2nd ed. (2026), ch. 10 “Incident Management and On-Call” (“Measuring the Effectiveness of Incident Response”); DORA, A history of DORA’s software delivery metrics; Seagate, Hard disk drive reliability and MTBF / AFR; NIST/SEMATECH, e-Handbook of Statistical Methods, 8.1.6.1 “Exponential”.