Ask any engineering leader what number they report up the chain after a bad quarter, and there's a good chance it's MTTR. Mean time to recovery has become the default proof-of-work metric for reliability teams — the number you put in the slide deck to show the incident program is paying off. It's also one of the easiest numbers in all of operations to improve without actually improving anything.
Here's the trick: MTTR is an average, and averages are trivially gamed by volume. Fix forty trivial blips in five minutes each and one catastrophic outage in six hours, and your MTTR looks fine. Declare more incidents as "minor" and your MTTR drops. Auto-resolve flapping alerts before a human ever looks at them and your MTTR drops further. None of this makes your system more reliable. It just makes the dashboard prettier for the next leadership review.
The Metric Rewards the Wrong Behavior
The deeper problem is what MTTR teaches a team to optimize for. If the organizational incentive is "get the number down," the fastest lever isn't better systems — it's faster, shallower remediation. Restart the pod. Fail over the region. Roll back without understanding why. All legitimate first moves during an active incident, and all things that can resolve the symptom while leaving the actual defect sitting in the codebase, waiting for the next deploy to wake it back up.
I've sat in postmortems where the "resolution" section reads like a magic trick: service degraded, service restored, root cause still under investigation three weeks later. The team hit its MTTR target. The underlying bug shipped again in the next release because nobody was incentivized to go find it — the clock had already stopped.
This is the same failure mode that shows up whenever a single number becomes the mission instead of a proxy for one. The number stops reflecting reality and starts reflecting whatever behavior makes the number move.
What Actually Correlates With a Healthier System
None of this means recovery speed is irrelevant — a slow recovery from a real outage is genuinely bad for users, and getting faster at restoring service during a true crisis matters. The issue is treating the average as the whole story. A few things tend to say more about the actual health of a system than a single rolled-up average:
- The distribution, not the mean. A median recovery time of four minutes next to a 95th-percentile recovery time of six hours tells you something an average hides completely: you have a long tail of incidents your tooling and runbooks don't handle at all.
- Recurrence. Does the same failure signature show up again within weeks? A fast fix that doesn't stick is worse than a slow fix that does, and MTTR can't tell the two apart.
- Time to detection, separately from time to remediation. A team that resolves incidents quickly once paged but takes forty minutes to notice the problem in the first place has a monitoring gap, not a response-speed strength. Collapsing both into one "recovery" number buries the actual bottleneck.
- Whether the fix required a human improvising under pressure, or whether a documented, tested path existed. Speed that comes from one engineer's tribal knowledge isn't a repeatable capability. It's a single point of failure wearing a good scorecard.
Report the Shape, Not the Average
None of this is an argument against measuring recovery at all — it's an argument against letting one summary statistic stand in for the health of the whole response process. If you're going to report a number upward, report the tail alongside the median, and report recurrence alongside both. A team that fixes the same outage three times in a quarter, each time a little faster, is not getting more reliable. It's getting better at a drill it shouldn't still need.
The next time someone proposes "reduce MTTR by 20%" as a quarterly goal, the better question to put on the table isn't how to hit that number — it's what behavior that target will actually reward once engineers start optimizing for it. Usually the honest answer is a little uncomfortable. That discomfort is worth sitting with before the target goes on a slide.