"So, how fast do we recover when something breaks?"
It's a fair question from a manager, an exec, or a customer — and "uh, pretty fast usually?" is not a great answer. The grown-up answer is a number, and that number has a name: MTTR. It's one of a small family of incident metrics that turn "we're reliable, trust us" into something you can actually measure and improve.
Here's the whole alphabet soup, decoded.
The metrics, decoded
Each one measures a different slice of an incident's life. The "MTT" ones all mean Mean Time To something:
| Metric | Stands for | Measures | Lower is better? |
|---|---|---|---|
| MTTD | Mean Time To Detect | Problem starts → you notice | ✅ Yes |
| MTTA | Mean Time To Acknowledge | Alert fires → a human owns it | ✅ Yes |
| MTTR | Mean Time To Recovery/Repair | Incident starts → service restored | ✅ Yes |
| MTBF | Mean Time Between Failures | Average uptime between incidents | ❌ Higher is better |
| MTTF | Mean Time To Failure | Lifespan of a non-repairable thing | ❌ Higher is better |
The first three (MTTD, MTTA, MTTR) measure how well you respond. The last two (MTBF, MTTF) measure how often things break in the first place.
How an incident breaks down in time
These metrics aren't separate — they're stages of the same timeline:
Problem starts ──► Detected ──► Acknowledged ──► Recovered
└── MTTD ──┘ └─ MTTA ─┘
└────────────── MTTR ──────────────────┘
MTTR is the headline because it's the whole journey: from the moment things break to the moment they're fixed. And notice — MTTD is part of MTTR. If it takes you an hour to even notice an outage, your recovery time can never be under an hour, no matter how fast your fix is.
How to calculate them
The maths is simple — average the relevant durations over a period:
- MTTR = total downtime from incidents ÷ number of incidents. (Five incidents totalling 100 minutes of downtime → MTTR = 20 minutes.)
- MTBF = total operating time ÷ number of failures. (720 hours in a month, 4 failures → MTBF = 180 hours.)
Watch the average. "Mean" hides outliers. Four 5-minute incidents and one 3-hour outage average out to a respectable-looking MTTR — while completely hiding the 3-hour disaster. Look at the distribution, not just the mean (the same lesson as latency percentiles).
How to actually improve each one
Numbers are only useful if you can move them. Here's the lever for each:
| To improve… | Do this |
|---|---|
| MTTD (detect faster) | Better monitoring: frequent checks, multiple locations, alert on symptoms |
| MTTA (acknowledge faster) | Clear on-call + escalation; cut alert noise so real alerts get seen |
| MTTR (recover faster) | Runbooks, fast rollback, good root-cause info, practice |
| MTBF (break less often) | Fix root causes (via postmortems), add redundancy, reduce risky changes |
The single highest-leverage move? Lower MTTD. Faster detection shrinks MTTR directly and limits the damage — and it's the cheapest to improve, because it's mostly about good monitoring.
Common pitfalls
- Gaming the numbers. If "resolved" is declared the moment a fix is deployed (not when it's confirmed working), MTTR looks great and means nothing.
- Averages hiding pain. As above — always check the worst cases, not just the mean.
- Metrics as a stick. Use them to improve systems, not to punish people. (See blameless postmortems.)
- Measuring everything, improving nothing. Pick one or two to focus on per quarter.
The bottom line
| Metric | One line |
|---|---|
| MTTD | How fast you notice. Improve this first. |
| MTTA | How fast someone takes ownership. |
| MTTR | The headline: total time to recover. |
| MTBF | How long between failures — higher is better. |
Incident metrics turn reliability from a feeling into a number you can track and improve. Start by measuring MTTD and MTTR honestly, lean on monitoring to push them down, and use the trend — not a single month — to tell whether you're actually getting better.
It all starts with detecting faster — which is what uptime monitoring and good alerting are for.