What Is MTBF (Mean Time Between Failures)?

Last verified on Nov 8, 2026.

MTBF comes from hardware reliability engineering. It answers a plain question: on average, how long does a system run before it fails again? The metric moved into software and operations teams along with MTTR, and it travels badly unless you keep its assumptions in view.

Definition

The International Electrotechnical Commission defines mean operating time between failures, with the synonym MTBF, as the expectation of the duration of the operating time between failures. Its note adds that the term applies only to repairable items. For non-repairable items, the same vocabulary uses mean operating time to failure, MTTF.

MTBF = total operating time / number of failures

A service that ran for 90 days (2,160 hours) and had three outages has an MTBF of 720 hours, or about 30 days. Only operating time counts. Time spent down does not add to the numerator.

MTBF and Availability

NASA's reliability formulas tie MTBF to repair speed. Inherent availability is MTBF divided by the sum of MTBF and MTTR:

availability = MTBF / (MTBF + MTTR)

The formula shows two ways to the same goal: fail less often or recover faster. With an MTBF of 720 hours:

To a first approximation, halving repair time does as much for availability as doubling the time between failures, and it is often cheaper. That is why Google's SRE book describes reliability as a function of mean time to failure and mean time to repair, and puts emphasis on the second. See MTTR for how to measure it.

What MTBF Does Not Say

MTBF is an average, and a surprising one. The NASA formulas assume a constant failure rate, modeled by an exponential distribution. Under that assumption the probability of getting through one full MTBF without a failure is at most about 0.37 (the NASA document puts it at 0.3679 when the failure rate times the time reaches one). An MTBF of 720 hours does not mean 720 failure-free hours. It means that on average failures arrive that far apart, and most gaps will be shorter or longer.

The constant failure rate also has a meaning: the NASA document says it suits failures caused mainly by external, random stresses outside the design, and the item then has no memory of how long it has run. IEC's note says MTTF equals the reciprocal of the failure rate in that case.

Using It for Software and Services

Software failures often break that assumption:

• Failures cluster around changes. A deploy or config push causes bursts of incidents, not a steady random rate.
• Fixes change the system. After you fix a bug, the failure rate drops for good, so past gaps stop predicting future ones.
• "Failure" is a choice. An incident might count at a 1% error rate or at a full outage. Different counts give different MTBFs.

None of that makes the metric useless. It makes the definition matter. A workable convention for services: define a failure as an incident that breached the SLO, count calendar time in the window as operating time, and read MTBF as a trend. A rising MTBF means incidents are getting rarer. A falling one is a signal to look for what changed.

To count failures from your own data, use an incident table and a window:

SELECT count(*) AS failures,
       (90 * 24)::float / NULLIF(count(*), 0) AS mtbf_hours
FROM incidents
WHERE severity <= 2
  AND impact_started_at >= now() - interval '90 days';

A NULL result means there were no qualifying incidents in the window, so there is no finite MTBF to report. This treats all 2,160 hours as operating time. Subtract downtime if you want strict operating time, which makes little difference when MTTR is small.

Alternatives

• Failure count and rate per week. Easier to explain, and it does not hide a long gap behind an average.
• The error budget. It ties failure frequency and length into one number.
• Per-component MTBF for disks and nodes. This is where the metric is at home, in the capacity and hardware layers. See crash loops and capacity risks.

For recurring failures that show up in logs before they page anyone, Sazabi's reliability issue detection tracks new kinds of errors as they appear.