MTTR (Mean Time To Recovery)

Mean Time To Recovery (also expanded as Repair, Restore, or Resolve) measures how fast you bounce back from incidents on average. It is the total time your incidents consumed divided by how many there were, and it is the metric most often quoted to summarize how well a team handles failure. Lower is better: a small MTTR means outages are short even when they happen.

Why it matters: in any realistic system failures are inevitable, so recovery speed often matters more than failure frequency. MTTR maps almost directly onto customer-facing downtime — halving it roughly halves the pain of every incident. It is also one of the few reliability numbers you can improve with process and tooling rather than expensive re-architecture.

A common misconception is that MTTR is a single, well-defined number. It actually blends several distinct phases — detection, acknowledgement, diagnosis, and repair — and teams disagree on exactly where the clock starts and stops. Two teams quoting very different MTTRs may simply be measuring different windows. Breaking the metric into MTTD, MTTA, and the repair phase reveals where the time really goes.

Because detection lag is part of the recovery clock, fast monitoring is one of the cheapest ways to lower MTTR. If your tooling needs five minutes to notice an outage, that lag is baked into every incident before any human can act; sub-minute checks remove most of it.