The definitions
- MTBF — Mean Time Between Failures. Average operating time between failures. Higher is better; improved by prevention (testing, redundancy, careful deploys).
- MTTR — Mean Time To Recovery. Average time from failure to restored service. Lower is better; improved by detection speed, runbooks, and practiced recovery paths.
- Availability ≈ MTBF ÷ (MTBF + MTTR). The relationship that ties them together.
Availability = MTBF ÷ (MTBF + MTTR)Worked example (illustrative).
Illustrative: MTBF of 720 hours (monthly failure) with MTTR of 0.72 hours (43 min) → 720 ÷ 720.72 = 99.9%. Halve the MTTR to 22 minutes and availability rises to 99.95% — without preventing a single failure.
Why MTTR is usually the better investment
Preventing all failures is unbounded work; recovering fast is bounded, practicable work. Detection (alerting that fires in minutes, not customer reports hours later), practiced runbooks, and one-command rollbacks move MTTR dramatically for small teams. Most outages' cost is duration, not occurrence.
The metrics' limits
- Averages hide distribution — ten 1-minute blips and one 10-minute outage share an MTTR but feel very different.
- 'Failure' needs a definition: full outage? Degraded core path? Count consistently or don't count.
- MTTR measured from detection understates user impact if detection lags — measure from user impact start where you can.
Assumptions and limits
- Formulas are definitional; examples are illustrative arithmetic.
- Metric definitions should be written down per team to stay consistent.
Common questions
What is a good MTTR?
It depends on your SLO — a 99.9% monthly target with monthly failures allows ~43 minutes of MTTR. As a direction: most small teams gain more by cutting detection time (alerting, status checks) than by optimizing the fix itself. Halving MTTR from 43 to 22 minutes lifts availability from 99.9% to 99.95% — without preventing a single failure.
How are MTBF and MTTR related to uptime?
Availability ≈ MTBF ÷ (MTBF + MTTR). Longer times between failures and faster recovery both raise availability — they're the two independent levers. MTBF, the average operating time between failures, improves through prevention work: testing, redundancy, careful deploys. MTTR, the average time from failure to restored service, improves through detection speed, runbooks, and practiced recovery paths.
Should we track MTTR from detection or from failure?
Track both if you can, but report from failure (user impact start) — that's the number users experienced. The gap between failure and detection is itself a metric worth shrinking, because MTTR measured from detection understates user impact whenever detection lags. Define 'failure' as well — full outage or degraded core path — and count consistently.
Published · Updated . Availability planning guides for small web teams. Models are planning tools, not guarantees.
Sources: Google SRE Book: Service Level Objectives — the availability framing behind the MTBF and MTTR relationship. Formulas are definitional; examples are illustrative arithmetic.
The next outage is a matter of when.
Be the team with the plan: a one-page runbook with named roles, severity levels, and the first-15-minutes sequence.