Incident Metrics

The four canonical incident metrics, what each measures, and which actually matter for SRE.

Overview

Four incident clocks

The incident lifecycle has four canonical time measurements. The industry uses them inconsistently, so precision matters in interviews and postmortems.

The definitions

MTTD: Mean Time To Detect — Issue start to monitoring detection — Observability quality. MTTD of 30 minutes means users see issues long before you know
MTTR: Mean Time To Resolve (or Recovery, or Repair) — Issue start, or detection, to resolution — Incident response quality; the most-cited metric. Say which start point you mean
MTBF: Mean Time Between Failures — Average time between failures of a repairable system: uptime + downtime / number_of_failures — Plans maintenance windows and reliability budgets; not actionable per service
MTTF: Mean Time To Failure — Average time to failure of a non-repairable component, such as disk drives — Hardware reliability; less common in software

TTR from incident start — Detection time: the "real" user-experienced duration
TTR from detection — Response time only

The reliability formula

Non-repairable — Availability = MTTF / (MTTF + MTTR)
Repairable — Availability = MTBF / (MTBF + MTTR)

> [!TIP] You can make failures rarer (raise MTBF) or recover faster (lower MTTR). For most modern services lowering MTTR is the higher-leverage lever: failures are inevitable, and minutes-to-recover beats hours dramatically.

What each part of MTTR drives

MTTD — Observability: better alerts, more sensitive thresholds, synthetic monitoring
MTT-Mitigate (detection to mitigation) — Runbook quality, automation, on-call training
MTT-Resolve (detection to full resolution) — Root-cause fix speed

> [!IMPORTANT] SRE Book Ch 14: optimize MTT-Mitigate over MTT-Resolve. Users care that the symptom is gone, not that you found the root cause.

Metrics that matter less

MTBF as a target — Can incentivize hiding small failures
Hours of uptime — Gamed by classifying outages narrowly
Single-incident MTTR — Noise; only the trend over many incidents matters

Healthy benchmarks (industry surveys)

MTTD — < 5 minutes for symptom-driven alerts; < 15 minutes for slow burns
MTT-Mitigate — < 30 minutes for P1; < 1 hour for P2
MTT-Resolve — 4-24 hours common, depending on root-cause complexity
MTBF — Highly service-dependent; tracked for trends, not absolute targets

Key concepts

MTTD: Mean Time To Detect. Issue start → monitoring fires. Drives observability investment.
MTTR: Mean Time To Resolve / Recovery. Definition varies; specify "from issue start" or "from detection." The most-cited metric.
MTT-Mitigate: Sub-component of MTTR: detection → symptom mitigated (regardless of root cause). The user-experienced duration. SRE-correct optimization target.
MTBF: Mean Time Between Failures. For repairable systems. Tracked for trend; rarely a useful target.
MTTF: Mean Time To Failure. For non-repairable hardware (disks, etc.). Less common in software.
MTTI / MTTA (synonyms you will hear): Mean Time To Identify / Acknowledge — the ITIL and PagerDuty names for the detection phase this topic calls MTTD. Critical difference: those frameworks treat the phase as sitting BEFORE MTTR and add the two (total downtime = MTTI + MTTR), whereas the Google SRE model nests detection INSIDE MTTR. See the Reliability Math topic for the reconciliation and the arithmetic.
Availability formula: Availability = MTBF / (MTBF + MTTR). Improving MTTR is usually the higher-leverage lever.

When to use it

Postmortem analysis — break down each incident's MTTD / MTT-Mitigate / MTT-Resolve
On-call program review — track MTTR trend over months; investigate regressions
Observability investment — slow MTTD is the metric that justifies more monitoring
Setting SLOs — availability math from MTBF / MTTR informs the SLO target

Interview questions

Define MTTD, MTTR, MTBF — and which matters most for SRE?
My MTTR is 4 hours. How do I diagnose it?
What's the relationship between availability targets and MTTR?