08.01 · Concept
MTBF, MTTR, and Their Limits
Say why MTTR is an unreliable measure of reliability, and what to use instead.
MTTR is a weak reliability signal because repair times are usually uneven, user impact varies, and correlated failures break the assumptions behind simple averages. Prefer SLOs, error budgets, request success ratios, latency targets, percentiles, burn rates, and separate detection, mitigation, and recovery timelines.
What this lesson answers
- why is MTTR a bad reliability metric
- what should replace MTTR for service reliability
- how do SLOs handle incident impact better
Notes
MTBF, MTTR, and Their Limits — MTBF and MTTR exist to summarize failure frequency and repair speed, but without understanding their distribution and user impact they hide bursty outages, long-tail recovery, and correlated failures that break real reliability planning.
Key Concepts: - ; if a service runs hours with incidents, hours. - ; repairs of , , and minutes give minutes, hiding the -minute…
References
Common questions
- Why is average time to repair misleading?
- An average hides the shape of the incident set. A service can have many tiny fixes and one severe outage, yet the mean still looks acceptable. It also says little about how many users were affected, whether failures were related, or whether the service had actually recovered from a customer perspective.
- What should I use instead of MTTR?
- Use SLOs tied to user-visible behaviour, such as successful request ratio, latency, or availability over a rolling window. Pair them with error budgets and burn-rate alerts. That makes reliability measurable in terms of customer impact, rather than the internal duration of incident handling.
- Should incident duration still be measured?
- Yes, but split it into separate timelines. Time to detect, time to mitigate customer impact, and time to full recovery answer different operational questions. A rollback may restore users quickly while cleanup, consistency checks, or root-cause work continue much longer.