MTTR: The Metric That Saves Your Nights

You can't prevent every outage — but you can learn to recover fast. An overview of MTTR: what it measures, how to compute it honestly, how to reduce it, and why you should never turn it into a blind KPI.

It’s three in the morning, an alert fires, and the only question that matters isn’t “why did it break?” but “how long until it’s fixed?”. Trying to prevent every outage is an illusion: complex systems always end up failing. The real measure of a team’s maturity isn’t its ability to never fail, but its ability to recover fast. That’s what MTTR measures — provided you know how to read it.

This article reads on two levels. The main thread is enough to get started; the “Going deeper” boxes add the depth that’s useful to anyone already running operations day to day.

I. The real problem: you can’t prevent everything  

For a long time, reliability was thought of as the absence of failure: the more rarely a system goes down, the better it is. That view has a fatal limit — it assumes you can foresee everything. Beyond a certain complexity, failure modes become countless, and the next outage will come from a place nobody anticipated.

Hence a shift of perspective, at the heart of SRE culture: since you can’t eliminate failures, you have to optimize recovery. Compare two services over a year:

• Service A: goes down once, but stays down for 8 hours. Downtime: 8 h.
• Service B: goes down 12 times, but recovers in 5 minutes. Downtime: 1 h.

From the user’s point of view, service B — supposedly twelve times more “fragile” — is eight times more reliable. It’s this shift of focus, from avoidance to recovery, that MTTR puts into numbers.

Going deeper. This is also the foundation of error budgets: an SLO (Service Level Objective) of 99.9% grants ~43 min of downtime per month. As long as the budget isn’t spent, you favor velocity; when it is, you freeze releases and invest in reliability. MTTR then becomes the lever that lets you “hold” the budget despite more frequent incidents.

II. What is MTTR exactly?  

MTTR stands for Mean Time To Recovery. It’s the average time between the start of an incident and the return of the service to normal.

MTTR doesn’t live alone. It belongs to a family of metrics that follow the timeline of an incident:

 outage         detection      acknowledged        service restored     cause fixed
   │                │                 │                   │                   │
   └── MTTD ────────┤                 │                   │                   │
                    └──── MTTA ───────┤                   │                   │
                                      └──── diagnosis ────┴──── repair ───────┘
   └──────────────────────── MTTR (recovery) ────────────────────────────────┘

The key distinction: MTBF measures the frequency of failures (how well you avoid them), MTTR measures the speed of recovery (how well you absorb them). Together they describe real reliability — but MTTR is the one you have the most leverage on in the short term.

Going deeper. The “R” in MTTR is a trap: depending on the team it means Recovery, Repair, Resolve, or Respond — and these aren’t the same boundaries. Above all, distinguish service recovery (the customer no longer suffers anything — often a rollback or a workaround) from root-cause resolution (the real fix, sometimes days later). Measuring one while thinking you measure the other distorts everything. Set the convention in advance: most mature teams steer by time to mitigate (service restored), not full resolution.

III. How to compute it (and why the average lies)  

The basic calculation is simple:

MTTR = total downtime / number of incidents

Over a month with 4 incidents for 2 hours of total downtime, MTTR is 30 minutes.

But here’s the trap, and it’s a big one: the average lies. Take seven incidents, in minutes:

5, 6, 7, 8, 10, 12, 240

• Mean (MTTR): 288 / 7 ≈ 41 minutes
• Median: 8 minutes

No incident lasted 41 minutes. The mean describes an incident that doesn’t exist, entirely pulled by the 240-minute case. This is the rule rather than the exception: recovery times are heavy-tailed — many short cases, a few monsters that crush the average.

For this reason, never look at MTTR alone:

• Track the distribution: median and percentiles (p50, p90) tell a far more honest story than the mean.
• Look at the trend over time, not the absolute value: is it dropping from one quarter to the next?
• Beware small volumes: with 3 incidents, no average means anything.

Going deeper. The VOID report (Verica Open Incident Database, Courtney Nash) showed, across thousands of real incidents, that durations follow a distribution close to log-normal, with very high variance — to the point that the mean and standard deviation are not statistically valid summaries. The study also finds a weak correlation between incident frequency and duration. Practical conclusion: treat MTTR as an internal learning signal (look at the shape of the distribution and its extreme values), never as a steering KPI or a contractual commitment. What teaches you the most isn’t the median incidents — it’s the tails.

IV. Breaking MTTR down to understand it  

MTTR isn’t a single block: it’s a chain of stages, and each is a distinct lever.

1. Detect — the time for the problem to be spotted (by monitoring or, worst case, by an unhappy customer).
2. Alert and take charge — the time for a human to be notified and start acting.
3. Diagnose — often the longest phase: understanding what is breaking and why.
4. Repair — applying the fix or the workaround.
5. Recover — verifying that the service has truly returned to normal.

The value is huge: this breakdown turns a fuzzy number into precise targets. An MTTR dragged down by late detection isn’t cured the same way as an MTTR weighed down by endless diagnoses. Instrument each segment (timestamp detected / acknowledged / mitigated / resolved in your incident tool) and you’ll know exactly where to invest.

Going deeper. In most organizations, the dominant phase isn’t repair but diagnosis — and its cost is directly correlated with the quality of observability and the spread of operational knowledge. A system where only one person can read the symptoms has a diagnosis MTTR that explodes as soon as they’re away. Reducing MTTR is therefore as much a knowledge-transfer problem as a tooling one.

V. The levers to reduce MTTR  

Each stage of the chain has its concrete remedies:

• Reduce detection → solid observability (metrics, logs, traces via OpenTelemetry, Grafana/Datadog dashboards) and above all alerts wired to the right symptoms.
• Reduce time to take charge → an equipped on-call setup (PagerDuty, Opsgenie…), with healthy rotations and an unambiguous escalation policy.
• Reduce diagnosis → tested runbooks that lead from a symptom to actions, readable dashboards, distributed tracing, and operational knowledge that’s shared rather than concentrated.
• Reduce repair → automating recovery: one-click rollback, canary/blue-green deployments, feature flags and kill switches to disable a faulty component without redeploying.
• Learn for next time → blameless postmortems that turn every incident into a durable safeguard — and therefore a shorter MTTR next time.

Going deeper. Two practices change the game radically. First, alerting on an SLO’s burn rate (Google’s multi-window / multi-burn-rate approach) rather than on static thresholds: less noise, more accurate detection, so a lower MTTD. Second, progressive delivery (canary + automatic rollback triggered by metrics): it makes repair nearly instantaneous and often without human intervention — the best MTTR is the one a human never even had to handle. Finally, train the chain in peacetime through game days: a runbook that’s never been tested is a fiction.

The best time to reduce your MTTR is when everything is fine. None of these levers can be improvised in the middle of an outage.

VI. MTTR and availability: the formula that ties it all together  

Why so much attention on MTTR? Because it weighs directly on availability, just as much as failure frequency does:

Availability = MTBF / (MTBF + MTTR)

You improve your availability in two ways: fail less often (MTBF ↑) or recover faster (MTTR ↓). For most teams, reducing MTTR is the fastest and cheapest lever — acting on failures you already suffer is more accessible than eliminating failures you haven’t seen yet.

What “recovering well” means in tolerated downtime:

Halving your MTTR halves the time your users are impacted — without having to make the system perfect.

Going deeper. This formula is a simplification: it assumes independent failures and regular durations, which, as we saw, is false. In practice, you don’t steer availability with MTBF/(MTBF+MTTR) but with an SLO measured over a rolling window (e.g. 99.9% over 28 days) and its error budget. The formula remains an excellent reasoning tool; it isn’t a measuring instrument.

VII. Measuring MTTR without fooling yourself  

• Confusing the average with reality. The heavy tail makes the mean misleading: always cross-check with the median and percentiles.
• Dressing up the metric. As soon as a number becomes a target, you’re tempted to manipulate it: closing an incident “technically resolved” while users are still impacted, counting only the “real” outages, or reclassifying an incident as a “degradation.” A prettified MTTR saves no nights.
• Optimizing MTTR at the expense of everything else. Recovering fast by sweeping the dust under the rug (a restart that hides the bug) makes the failure come back. Speed of recovery doesn’t mean sloppiness.
• Turning it into a KPI or an SLA. This is the senior’s trap. Given its variance, MTTR is a poor contractual target and an easy one to game (Goodhart’s law: “when a measure becomes a target, it ceases to be a good measure”).

Going deeper. So, should you throw MTTR away? No — but change how you use it. Use it internally, to learn, by looking at the distribution and the extreme incidents, never as a displayed KPI or a customer commitment. And complement it with less manipulable measures: the number of incidents, the percentage of incidents above a threshold (e.g. “90% recovered in < 30 min”), and above all real impact — the affected user-minutes, which weight duration by the number of users hit. A 4-hour incident at 3 a.m. on a secondary service doesn’t carry the weight of a 10-minute one in the middle of the day on payments.

VIII. Where to start  

If you’re new to the subject:

1. Timestamp your incidents (start, detection, acknowledgment, recovery).
2. Compute the median recovery over a few months — not the mean.
3. Write a first runbook for your most frequent outage.
4. Look at which stage (detect / diagnose / repair) costs you the most, and attack that one.

If you already run operations:

1. Switch your alerts to SLO burn rate to bring down the MTTD.
2. Make rollback trivial and, if possible, automatic (progressive delivery).
3. Track the distribution of MTTR and the user-minutes, not a single average.
4. Stress-test the whole chain with a quarterly game day.

Conclusion  

MTTR marks a healthy reversal: reliability isn’t about never falling, but about getting back up fast. It’s a humble metric — it admits that failures will happen — and a deeply useful one as long as you read it correctly: as a distribution rather than an average, as a learning signal rather than a trophy.

Remember the essential: a good MTTR isn’t decreed in the middle of an outage, it’s prepared in peacetime. Observability, runbooks, healthy on-call, automated rollback, postmortems: every brick laid while things are fine is a night’s sleep gained when things go wrong.

Useful links  

• Google SRE Book — Service Level Objectives
  The SRE framework for reliability: SLIs, SLOs, error budgets, and where recovery metrics fit in.

• Google SRE Workbook — Alerting on SLOs (burn rate)
  The multi-window / multi-burn-rate alerting method, a direct lever for reducing MTTD.

• Atlassian — Incident metrics: MTTR, MTBF, MTTA, MTTF
  A clear overview of incident metrics, their definitions, and their differences.