48.9k
Mean time to repair (MTTR) is a reliability metric that measures the average time from when an incident begins to when service is restored, calculated as total incident duration divided by the number of incidents. Teams track it alongside MTTD, MTTA, and MTBF to judge how quickly they detect, acknowledge, and resolve production failures.
The metric family comes from hardware reliability engineering and moved into site reliability engineering practice with mixed results: DORA's research tracked "time to restore service" for years before replacing it with failed deployment recovery time in 2023, and Google has published a statistical case against reading trends into the mean at all.
What does MTTR stand for?
MTTR stands for mean time to repair, but the "R" is read at least four ways (repair, recovery, respond, and resolve), and each variant measures a different clock interval. Any team reporting MTTR should state which expansion it uses, because a respond-MTTR of 5 minutes and a resolve-MTTR of 4 hours can describe the same incident.
The four expansions:
- Mean time to repair. Time spent actively fixing the fault, from the start of repair work to the fix landing. The original hardware-maintenance meaning.
- Mean time to recovery (or restore). Time from incident start to full service restoration, including detection and diagnosis. The most common software reading, and the one this page uses.
- Mean time to respond. Time from the alert firing to a responder actively working the incident, excluding detection latency.
- Mean time to resolve. Time from incident start until the underlying cause is fixed, which can extend well past the moment users stop noticing.
How do you calculate MTTR?
MTTR is calculated by summing the duration of every incident in a period and dividing by the incident count: MTTR = total downtime ÷ number of incidents. Under the recovery reading, each duration runs from incident start to service restoration. Consistent start and end timestamps matter more than the arithmetic itself.
A worked example over one quarter with three incidents:
- Incident 1: 22:04 to 22:49 (45 minutes)
- Incident 2: 09:30 to 09:50 (20 minutes)
- Incident 3: 14:00 to 18:10 (250 minutes)
MTTR = (45 + 20 + 250) ÷ 3 = 105 minutes.
Two of the three incidents were over in under 45 minutes, so the 105-minute "average" describes none of them. Incident durations are heavily skewed, with many short incidents and a long tail, the same property that makes averages misleading for latency, covered in percentiles vs averages. Štěpán Davidovič's Google report, Incident Metrics in SRE (2021), used Monte Carlo simulation to show that MTTR-style statistics are "poorly suited for decision making or trend analysis": at typical incident volumes, month-to-month movement is mostly noise.
MTTR vs MTTD vs MTBF: what's the difference?
MTTR measures average recovery time, MTTD measures average detection time, MTTA measures average time to acknowledge an alert, and MTBF measures average time between failures. The first three describe how a team responds once something breaks; MTBF describes how often things break in the first place.
| Metric | What it measures | Formula | Improved by |
|---|---|---|---|
| MTTD (mean time to detect) | Incident start → detection | Σ detection delays ÷ incidents | Alert quality, symptom-based alerting, telemetry coverage |
| MTTA (mean time to acknowledge) | Alert fired → responder engaged | Σ acknowledgement delays ÷ incidents | On-call rotations, paging hygiene, alert routing |
| MTTR (mean time to recovery) | Incident start → service restored | Σ incident durations ÷ incidents | Fast diagnosis, runbooks, rollbacks, feature flags |
| MTBF (mean time between failures) | End of one incident → start of the next | Total operating time ÷ incidents | Testing, redundancy, gradual rollouts |
The metrics nest: under the recovery reading, MTTD and MTTA are components of MTTR. A team with a 40-minute MTTR and a 25-minute MTTD has a detection problem, not a firefighting problem.
What is a good MTTR?
There is no single good MTTR: a defensible target depends on incident severity, the system's blast radius, and which "R" is being measured. Cross-company benchmark tables are unreliable because organizations count incidents differently. The most useful published reference is DORA's failed deployment recovery time.
Two practices make the number meaningful:
- Split by severity. A SEV1 that takes checkout down and a SEV4 cosmetic bug should not share a target; an aggregate MTTR is dominated by whichever class occurred most that month.
- Scope the clock to a defined trigger. The 2023 Accelerate State of DevOps report did exactly this, replacing "time to restore service" with failed deployment recovery time: the time to recover from a deployment that fails and requires immediate intervention. Elite performers recover in under an hour, while the lowest cohort takes between a week and a month.
How do you reduce MTTR?
Reduce MTTR by shrinking its stages independently: detect faster with symptom-based alerts, diagnose faster with queryable high-cardinality telemetry, mitigate faster with rollbacks and feature flags, and verify recovery with the same signals that raised the alert. Diagnosis is usually the longest stage, so telemetry query speed is the largest single lever.
Stage by stage:
- Detect (MTTD). Alert on user-visible symptoms (error ratio, latency against an objective) rather than internal causes. Alerting tied to SLOs and error budgets catches what users feel and skips what they don't.
- Diagnose. Responders move from "something is wrong" to "this is why" by interrogating logs, traces, and metrics. The narrower the questions the telemetry can answer, the longer this takes.
- Mitigate. Restore service before fixing root cause: roll back the deploy, flip the feature flag, shed load. Rehearsed runbooks and clear roles, covered in the incident response process, remove decision latency.
- Verify and learn. Confirm recovery in the telemetry, then run a blameless postmortem, per the Google SRE book's postmortem chapter, so the same failure buys a lasting fix.
Common misconceptions about MTTR
- A falling MTTR proves reliability is improving. At typical incident counts the mean is noise-dominated; Davidovič's simulations found even substantial real improvements often stay invisible in MTTR. Look at the distribution, or the median, over longer windows.
- MTTR benchmarks are comparable across companies. Incident definitions, severity thresholds, and clock start/stop rules differ, so published averages mostly measure bookkeeping, not operational skill.
- MTBF works for software the way it works for hardware. MTBF assumes failures arrive randomly as parts wear out. Software failures cluster around deploys and config changes, so software MTBF tracks release habits more than component reliability.
- A low MTTR makes incident frequency unimportant. Recovering in 10 minutes, 40 times a quarter, still burns error budget and user trust. MTTR and MTBF only mean something read together.
Measuring MTTD and MTTR with ClickStack
Every metric on this page is an aggregation over timestamped events, which makes incident metrics a database query. ClickStack, the open-source ClickHouse observability stack, stores logs, metrics, and traces as wide events in ClickHouse via native OpenTelemetry ingestion; HyperDX, the stack's UI, is where alerts fire (the MTTD term) and where responders run the high-cardinality queries diagnosis depends on. With incident timestamps landed in a table, the reporting is one query:
-- Incident metrics per severity, with means and medians side by side
SELECT
severity,
avg(resolved_at - started_at) AS mean_time_to_recover,
median(resolved_at - started_at) AS median_time_to_recover,
avg(detected_at - started_at) AS mean_time_to_detect,
count(*) AS incidents
FROM incidents
WHERE started_at >= now() - INTERVAL 90 DAY
GROUP BY severity;Computing the median next to the mean costs one line and produces a number the long tail can't distort. Because ClickStack retains raw events rather than pre-aggregated rollups, the store that pages the on-call also answers the arbitrary follow-up questions that shrink diagnosis.
Frequently asked questions
Is MTTR the same as MTTD?
No. MTTD (mean time to detect) measures the average delay between a failure starting and the team noticing it; MTTR (mean time to recovery) measures the average time from failure start to service restoration. Under the common recovery reading, MTTD is one component inside MTTR, because detection time is part of the recovery clock.
How does observability improve MTTR?
Observability shrinks the two slowest stages of recovery. Detection latency falls when alerts fire on rich, real-time telemetry instead of coarse health checks, cutting MTTD. Diagnosis speed rises when responders can query high-cardinality logs, traces, and metrics to answer arbitrary questions about a novel failure, instead of waiting for hypotheses to be confirmed manually.
What replaced MTTR in the DORA metrics?
Failed deployment recovery time. The 2023 Accelerate State of DevOps report retired "time to restore service" in favor of a metric scoped to one trigger: recovering from a deployment that fails and needs immediate intervention. The narrower definition makes the clock start unambiguous and the results comparable across teams.
Should teams stop tracking MTTR?
No, but small monthly movements are not worth reacting to. MTTR stays useful as a coarse health signal when it is split by severity, reported alongside the median and incident count, and judged over quarters rather than weeks.
