MTTR / MTBF Calculator
Calculate Mean Time To Recovery, Mean Time Between Failures, and the availability they imply.
Formula last reviewed 4 August 2026 · How we verify our calculators
Availability (from MTBF/MTTR)
- MTTR (mean time to recovery)
- 30.0 min
- MTBF (mean time between failures)
- 10800.0 min
Updates live as you type
Frequently asked questions
Mean Time To Recovery (or Repair) is the average time to restore service after an incident: total downtime ÷ number of incidents. 120 minutes across 4 incidents is an MTTR of 30 minutes.
Mean Time Between Failures is the average healthy interval between incidents: total uptime ÷ number of incidents. It measures how often things break, while MTTR measures how fast you fix them.
Availability = MTBF ÷ (MTBF + MTTR) × 100. With MTBF 10,800 min and MTTR 30 min, that is ≈ 99.72%.
It is an alternate lens on the same reliability. The SLI-based view counts good vs bad events; the MTBF/MTTR view decomposes availability into failure frequency and recovery speed — useful for deciding whether to invest in preventing incidents or in recovering faster.
Both improve availability, but reducing MTTR is often faster to act on — better detection, runbooks and rollbacks shorten recovery, whereas raising MTBF means preventing failures, which is usually slower and harder.
The same 99.72% availability, reached two completely different ways
120 minutes total downtime, 43,200 minutes total uptime (30 days), across 4 incidents: MTTR is 120 ÷ 4 = 30 minutes per incident, MTBF is 43,200 ÷ 4 = 10,800 minutes — 7.5 days of healthy operation between failures on average. Combined, availability is 10,800 ÷ (10,800 + 30) × 100 ≈ 99.72%. Now halve the incident count to 2, keeping total downtime and uptime fixed: MTTR doubles to 60 minutes per incident (fewer, longer outages), MTBF doubles to 21,600 minutes (rarer failures) — and availability lands close to the same 99.72% figure. Two very different incident patterns, "frequent but quick" versus "rare but slow," produce nearly the identical headline number, which is exactly why this decomposed view is useful alongside a single availability percentage rather than instead of it.
What this calculator measures instead of the usual SLI view
Availability can be measured two ways. The SLI/SLO view counts successful versus failed events directly. This calculator takes the incident-based view instead: deriving availability from how often failures happen and how fast recovery follows, using total downtime, total uptime and the number of incidents as inputs.
The two metrics point at different investments. A high MTTR says incidents drag on — improve detection, alerting, runbooks and rollback so you recover faster. A low MTBF says incidents happen too often — invest in testing, redundancy and change safety to prevent them. Because availability depends on both, teams often get the quickest wins from cutting MTTR, since shortening recovery is usually more tractable than eliminating failures entirely.
This is the same underlying reliability your SLI and error budget describe, decomposed into frequency and speed. Use it alongside the SLO calculator to connect incident metrics back to your objectives and error budget — a service consistently blowing its budget often has an MTTR or MTBF problem you can name and target directly.