Mean time to recovery (MTTR) is one of the most commonly cited reliability metrics, and one of the most commonly misused — usually not through bad intent, but through averaging away exactly the information that made the metric worth tracking in the first place.

What MTTR actually measures

MTTR measures the average elapsed time between an incident starting and service being restored, across a set of incidents over a given period. Atlassian’s overview of common incident management metrics places it alongside several related measurements that are worth distinguishing clearly, since the acronyms are easy to conflate:

  • MTTD (mean time to detect) — how long it takes to notice an incident is happening at all, from when it actually started.
  • MTTR (mean time to recovery) — how long it takes to restore service once an incident is being actively worked, sometimes measured from detection rather than from the incident’s true start.
  • MTTF (mean time to failure) — how long a system typically runs before an incident happens in the first place, a measure of reliability rather than response.

Conflating these — quoting an MTTR figure that’s actually measuring something closer to MTTD, for instance — produces numbers that look precise but don’t actually mean what they’re assumed to mean.

The averaging problem

MTTR’s core weakness is structural: averaging recovery time across incidents of very different severity and cause tends to produce a number that doesn’t represent any specific real incident well. A handful of minor incidents resolved in minutes and one severe incident that took many hours to fully resolve, averaged together, can produce an MTTR that looks moderate — while actually describing neither the typical minor incident nor the severe outlier accurately. A single unusually long incident can also skew an average sharply for a reporting period, making recovery performance look worse than the typical case actually was.

This is a common and specific version of a general problem with averages: they discard the shape of the underlying distribution. Reporting a median recovery time, or breaking MTTR down by incident severity rather than blending everything into one figure, generally gives a more honest picture than a single blended average — the same reasoning behind tracking latency percentiles instead of a single average rather than one blended mean.

Why MTTR alone is an incomplete reliability picture

MTTR measures response effectiveness after an incident starts; it says nothing about how often incidents happen in the first place, which is a separate and arguably more fundamental question about system reliability. A system with a low MTTR but frequent incidents may deliver a worse overall experience than one with a higher MTTR but rare incidents — recovery speed and incident frequency are both necessary parts of the reliability picture, and neither one alone is sufficient. This is part of why SLOs and error budgets are generally a more complete reliability framework than any single incident-response metric on its own: they account for both how often something goes wrong and how much impact it has, rather than measuring response speed in isolation.

Using MTTR usefully despite its limits

MTTR remains a genuinely useful metric when used carefully: tracked over time to spot trends, segmented by severity rather than blended into one number, and considered alongside incident frequency rather than in isolation. Used this way, it can meaningfully validate whether investments in on-call and incident response process, or in better runbooks, are actually paying off in faster real recoveries — as long as the number being reported hasn’t already averaged away the detail that would show that.

Key takeaway

MTTR measures average recovery time, but a single blended average across incidents of very different severity often obscures more than it reveals, and it’s frequently confused with related but distinct metrics like MTTD and MTTF. Segmenting by severity, preferring a median over a mean, and pairing MTTR with incident frequency data gives a genuinely more useful picture than quoting a single MTTR figure on its own.

This article explains general incident metrics concepts; specific measurement approaches should be adapted to your team’s needs. See our disclaimer.