What is MTBF?

Divide total operational time by the number of failures in that period. A service running 720 hours in a month with four failures has an MTBF of 180 hours.

The measurement counts the time the system was operating between failures, and it applies to repairable systems, meaning things that are fixed and returned to service rather than replaced. Which events count as failures has to be defined consistently, since including minor degradations produces a very different number than counting only full outages.

MTBF is the frequency half of the reliability picture, and it is the half that reliability engineering can most directly improve.

• Trend signal: a rising MTBF over time is evidence that stability work is effective.
• Component comparison: identifies which parts of a system fail disproportionately often.
• Capacity planning: failure frequency informs how much redundancy is needed.
• Maintenance scheduling: known failure intervals support preventive replacement.

Averages conceal distribution. A system with one failure every 180 hours and a system with four failures in one bad week and nothing for the rest of the month share an MTBF and behave nothing alike.

MTBF also says nothing about impact. Frequent trivial failures that users never notice produce a poor MTBF, while one catastrophic monthly outage produces a good one. Read alone, it can point reliability effort in exactly the wrong direction.

MTBF measures how often failures occur. MTTR measures how long they last. Together they determine availability: a system that fails rarely but takes a day to recover can be less available than one that fails often and recovers in seconds.

The two also respond to different work. MTBF improves through better testing, architecture, and change management. MTTR improves through better detection, tooling, and runbooks. Teams generally find MTTR the faster lever early on, since preventing failures is harder than recovering from them quickly.