Skip to main content
MTBF stands for mean time between failures: the average operating time a system runs between one failure and the next. It is calculated by dividing total uptime by the number of failures over a period. Where MTTR measures how fast you recover from incidents, MTBF measures how often they happen — together they determine a system’s availability.

​
How do you calculate MTBF?

Only count time the system was actually running: downtime spent repairing a failure belongs to MTTR, not MTBF. The metric originated in hardware reliability engineering, where it described physical components; in software operations it is usually applied per service, counting incidents or outages as “failures.”

​
Worked example

A service is observed for a 30-day month (43,200 minutes) and fails three times, with outages of 60, 30, and 90 minutes. Total downtime = 60 + 30 + 90 = 180 minutes. Total uptime = 43,200 − 180 = 43,020 minutes. MTBF = 43,020 / 3 = 14,340 minutes, or roughly 9.96 days between failures. For the same period, MTTR = 180 / 3 = 60 minutes.

​
What is the difference between MTBF and MTTR?

MTBF and MTTR answer complementary questions:
  • MTBF: how often do we break? Improving it means preventing failures — better testing, safer deploys, redundancy, capacity planning, and fixing the root causes surfaced in retrospectives.
  • MTTR: how fast do we fix it? Improving it means recovering faster — better detection, paging, runbooks, and rollback.
A high MTBF with a terrible MTTR describes a system that rarely fails but is catastrophic when it does. A low MTBF with an excellent MTTR describes a system that fails constantly but self-heals quickly. Neither number alone tells you whether users are having a good time — for that you combine them. Modern reliability thinking (popularized by the DORA research and the SRE community) tends to prioritize reducing MTTR over maximizing MTBF: failures are inevitable in complex systems, and teams that recover in minutes can ship faster than teams that try to prevent every failure. But MTBF still matters — if the same service fails every week, no amount of fast recovery makes that acceptable.

​
How do MTBF and MTTR determine availability?

Availability is the fraction of time a system is up, and it falls directly out of the two metrics:
Intuitively: each failure cycle consists of MTBF minutes of uptime followed by MTTR minutes of repair, so availability is uptime’s share of the whole cycle. Using the worked example above: The formula also shows two routes to any availability target. To reach 99.9%, you can make failures rarer (raise MTBF) or make recovery faster (cut MTTR). Halving MTTR from 60 to 30 minutes in the example lifts availability to 99.79% — the same effect as roughly doubling MTBF, and often far cheaper to achieve.

​
How should you use MTBF in practice?

  • Segment by service and severity. A fleet-wide MTBF blends critical and trivial services into a meaningless average.
  • Watch the trend, not the absolute. A declining MTBF for a specific service is an early warning of accumulating tech debt or scaling limits.
  • Pair it with an error budget. MTBF and MTTR describe past reliability; an error budget turns an availability target into a forward-looking spending allowance.
  • Feed it back into planning. Services with the worst MTBF are the strongest candidates for reliability investment in the next quarter.
Rootly derives failure frequency and duration metrics automatically from your incident data — see default metrics for the available measures and groupings. Browse the full incident management glossary.