Developer/Availability/Reliability/Fundamentals/mtbf-mttr-and-reliability-math

MTBF, MTTR, and Reliability Math

Concept

Where an SLO frames reliability as a target a team commits to (see SLIs, SLOs, and Error Budgets), MTBF and MTTR are the underlying physical/operational quantities that determine what reliability a given architecture can actually deliver. MTBF (Mean Time Between Failures) is the average duration a component or system runs before failing. MTTR (Mean Time To Repair/Recover) is the average duration it takes to restore service once a failure happens. Together they compose into the standard availability formula:

Availability = MTBF / (MTBF + MTTR)

A component with an MTBF of 1000 hours and an MTTR of 2 hours is available 1000 / 1002 ≈ 99.8% of the time. This formula makes explicit something the SLO framing can obscure: availability is a ratio of two independently improvable numbers, not one property. A system can hit the same availability target by either making failures rarer (raising MTBF, e.g. more reliable hardware, better input validation to prevent bad-state crashes) or by making recovery faster (lowering MTTR, e.g. automated failover, better runbooks, faster detection) — and in practice, MTTR is very often the cheaper lever to pull. Rearchitecting a system to fail less often is expensive and slow; instrumenting faster detection and automating the recovery path is frequently a bigger availability win for less engineering cost.

The formula also composes across an architecture, which is where it becomes a design tool rather than a reporting metric. For components in series — where any one component failing takes down the whole system, the common case for a request path through multiple hops with no redundancy — overall reliability is the product of each component's availability: A_system = A1 × A2 × ... × An. This is why a request path through five 99.9%-available services is not itself 99.9% available — it's 0.999^5 ≈ 99.5%, meaningfully worse than any single hop. For components in parallel — redundant instances where the system only fails if all of them fail simultaneously, availability instead climbs toward 100%: A_parallel = 1 − (1 − A1)(1 − A2)...(1 − An). Two independent 99% components in parallel yield 1 − (0.01 × 0.01) = 99.99% combined — each 9 of added redundancy buys roughly two more 9s of combined availability, at the cost of running duplicate capacity.

Tradeoffs

Lever	What it improves	Typical cost	Ceiling
Raise MTBF (fewer failures)	Root-cause reliability	Slow, expensive — hardware/code quality work, often requires redesign	Diminishing returns; failures never reach zero
Lower MTTR (faster recovery)	Time-to-restore per incident	Often cheaper — automation, better alerting, tested runbooks, faster failover	Bounded by detection + automation latency, not by system quality
Add redundancy (parallel components)	Whole-system availability, without touching per-component reliability	Duplicate infrastructure cost, and added coordination/failover-detection complexity (see Failure Detection and Split-Brain Avoidance)	Approaches but never reaches 100%; each added 9 costs disproportionately more
Reduce serial dependency count	Whole-system availability, without redundancy cost	Requires architectural simplification — fewer hops, batching calls, removing non-essential dependencies from the critical path	Bounded by what's actually removable from the request path

The series-vs-parallel math is the real argument for why microservice architectures need redundancy at every hop to hit an aggressive SLO: adding services to a request's critical path multiplies availability down, so each new dependency needs either very high individual availability or its own redundancy to avoid dragging the whole path's number down.

When to use / when not to

Use the series formula when auditing a request's critical path — sum up every service, database, and third-party call a single request depends on, and multiply their availabilities to see what the path can actually deliver, before setting an SLO the architecture can't support.
Use the parallel formula to justify (or challenge) a redundancy decision quantitatively — "adding a second AZ takes this component from 99.9% to 99.9999%" is a concrete, defensible number, not a vague appeal to "more redundancy is safer."
Favor MTTR investment (faster detection, automated failover, rehearsed incident response) over MTBF investment (rearchitecting for fewer failures) when both are on the table and time/budget is limited — it's usually the higher-leverage fix per unit of engineering effort.
Don't treat a single component's advertised MTBF (from a vendor spec sheet) as the system's real-world reliability — real failures include operator error, deployment mistakes, and dependency failures that a component-level MTBF number never captures.

Common pitfall

Computing an aggregate availability target from optimistic, independently-sourced component numbers without accounting for correlated failures. The parallel-redundancy formula assumes failures are statistically independent; two "redundant" database replicas in the same Availability Zone, behind the same power and network infrastructure, don't actually fail independently — a zone-level outage takes both down together, and the real combined availability is much closer to a single component's than the formula's optimistic multiplication suggests. Redundancy only delivers the math's promised uplift when the redundant components' failure modes are genuinely uncorrelated (different AZs, different Regions, different power/network paths).

Engineering Lens

The useful move in a reliability review is walking a specific critical user journey's dependency chain and multiplying its component availabilities out loud — it turns "we think this is reliable" into a falsifiable number, and it usually surfaces that the weakest link in a chain of otherwise-solid services is the one nobody added redundancy to because it "never fails." The MTTR side of the same conversation is where the highest-leverage, lowest-cost improvements usually live: teams that have never measured their own MTTR are almost always investing in the wrong lever, chasing marginal MTBF gains through code quality work when a faster on-call escalation path or an automated rollback would move the availability number more, for less effort.