MTBF — What is Mean Time Between Failures?

MTBF (Mean Time Between Failures) is the average time a system operates between one failure and the next. It is calculated by dividing total operational time by the number of failures in that period: a service that ran 900 hours and failed three times has an MTBF of 300 hours. A higher MTBF means a more reliable system. Where MTTR measures how fast you recover, MTBF measures how rarely you need to.

The metric comes from hardware reliability engineering, where it describes how long a physical component lasts before breaking. It transfers to software systems with one important adjustment: software does not wear out, so MTBF for a service measures the stability of the system and the change process around it rather than the endurance of a part.

How Do You Calculate MTBF?

The formula is:

MTBF = Total operational time ÷ Number of failures

Operational time counts only the periods the system was expected to be running. Time during which the service was deliberately offline for maintenance is normally excluded, as is time it was already down — MTBF measures the intervals between failures, not the failures themselves.

A worked example. A payments API is expected to run continuously across a 30-day month, which is 720 hours. During that month it failed four times, and the outages consumed 6 hours in total.

• Operational time = 720 − 6 = 714 hours
• Number of failures = 4
• MTBF = 714 ÷ 4 = 178.5 hours

So the service runs roughly 7.4 days between failures. Note what the number does not tell you: those four failures might have been evenly spread, or all four might have happened in one bad afternoon. MTBF is an average, and averages hide clustering — which is why it is read alongside the incident timeline rather than on its own.

MTBF is not a prediction. A 178-hour MTBF does not mean the next failure arrives in 178 hours. It is a historical rate, and it is only a useful forecast if the system and its failure modes stay roughly constant.

What is MTBF and MTTR? (And How the Metrics Fit Together)

MTBF is one of a family of incident metrics that are frequently confused. Each measures a different segment of the failure cycle:

The distinction between MTBF and MTTF is the one most often got wrong. MTBF applies to repairable systems — a service that fails, is fixed, and runs again. MTTF applies to non-repairable ones — a component that fails once and is replaced. For software services, MTBF is almost always the correct metric.

MTBF and MTTR are the diagnostic pair. Neither is meaningful alone, and reading them together tells you where to invest:

• High MTBF, high MTTR — failures are rare but painful. The problem is response: runbooks, alerting, escalation.
• Low MTBF, low MTTR — failures are frequent but well handled. The team is competent and tired. Invest in root causes before the on-call rotation burns out.
• Low MTBF, high MTTR — the urgent case. Both reliability and response need work.
• High MTBF, low MTTR — healthy. Watch for drift.

The pattern worth catching early is MTTR improving while MTBF falls. That combination means the team is getting better at firefighting a system that is getting worse, and it is invisible if you track response metrics alone.

What is Considered a Good MTBF?

There is no universal benchmark, and any source offering one without context is selling something. A good MTBF depends entirely on what the system does and what failure costs.

What makes the number meaningful is comparison against itself. Your MTBF last quarter is the only benchmark that reliably means anything. Cross-company comparisons fail because two teams almost never define "failure" the same way — one counts any alert, another counts only customer-visible outages, and their numbers are not on the same scale.

Some rough orientation for software services:

• Trending upward quarter over quarter is the signal that matters more than any absolute value.
• An MTBF shorter than your on-call shift means an engineer can expect to be paged on essentially every shift. That is a burnout trajectory regardless of how good the number looks in isolation.
• An MTBF measured across fewer than five failures is not a trend. For reliable services, use a quarterly or annual window rather than a monthly one.

Rather than chasing a target number, tie MTBF to a commitment you have already made. If your SLO allows a defined amount of unreliability, MTBF and MTTR together tell you whether the error budget is being spent on many small failures or a few large ones. Those two situations need different fixes.

Is a Higher or Lower MTBF Better?

Higher is better. MTBF measures the interval between failures, so a longer interval means a more reliable system. A service with an MTBF of 700 hours fails roughly half as often as one at 350.

This is the opposite of the recovery metrics, and the inversion is the most common source of confusion when the numbers appear side by side on a dashboard. MTBF up is good. MTTR, MTTA and MTTD up are bad. Any dashboard showing them together should make that explicit, because a green arrow next to a rising MTTR is a reporting error waiting to happen.

One caveat on chasing a higher number. MTBF improves when failures stop occurring — but it also improves when you stop counting them. Teams that quietly raise the threshold for what qualifies as a failure will see MTBF rise without the system changing at all. That is why the definition of failure has to be written down and stable.

Key Benefits of Tracking MTBF

• It separates reliability from responsiveness. Response metrics measure how well the team copes. MTBF measures whether the system is giving them less to cope with, which is the only sustainable direction.
• It justifies engineering investment. MTBF improves when underlying causes are fixed rather than worked around, so it is the metric that demonstrates whether remediation work paid off. That makes it the number to bring to a prioritisation argument about reliability work versus features.
• It grounds SLA and SLO conversations. Availability targets are easier to reason about when you know how often failure actually occurs, not just how long it lasts. Two services at 99.9% availability — one failing monthly for 43 minutes, one failing hourly for seconds — are very different products.
• It surfaces the burnout trajectory early. Failure frequency, not failure duration, is what determines how often someone is woken up.

Best Practices for Using MTBF

Define "failure" before you measure it, and write it down. MTBF is only comparable across periods if the threshold is stable. A team that starts counting degraded performance as failure mid-quarter will see MTBF collapse for reasons that have nothing to do with reliability — and will spend a week explaining a metric change as though it were an incident trend.

Scope it per service, never per organisation. An org-wide MTBF averages a stable billing service with a volatile ingestion pipeline into a number that describes neither and cannot be acted on. Per-service MTBF points at something you can fix.

Read it with MTTR, always. The pair is the diagnosis; either alone is a fragment. Put them on the same dashboard with the direction of "good" marked on each.

Treat small samples with suspicion. Three failures is not a trend, and a single unusual month will swing a monthly MTBF dramatically. Match the window to the failure rate.

Watch for definitional drift. Review annually whether "failure" still means what it meant when you set it. Drift is the most common reason a reliability metric improves without anything getting better.

Do not optimise MTBF in isolation. A team measured only on failure frequency has an incentive to avoid deploying, and deployment frequency and reliability are not actually in opposition — a system that ships small changes often typically has better MTBF than one that ships large changes rarely. Pair it with a delivery metric so the incentive stays honest.

MTBF in Software vs. Hardware

The metric was built for physical components, and most published MTBF guidance still assumes them — bearings, drives, industrial equipment. Two differences matter when applying it to a software service.

Software does not wear out. A hardware MTBF describes physical degradation over time, and a component's failure probability rises as it ages. Software fails from change, load and interaction with dependencies. A service that nobody touches and whose traffic is constant can run indefinitely. This means software MTBF is largely a measure of your change process, not your code's endurance.

Failure is a judgement, not an event. A bearing has clearly failed or not. A service can be slow, partially available, or broken for 3% of requests. Software MTBF therefore depends entirely on where you set the threshold — which is why the written definition matters far more here than it does in a maintenance context.

The practical consequence: benchmarks drawn from equipment reliability do not transfer, and neither do the target numbers. Use your own history.

The All Quiet Bridge

MTBF is only as good as the incident record behind it, and the record is usually the weak point. Failures resolved in a chat thread and never formally logged simply do not appear in the denominator — which means most teams' MTBF is quietly overstated, and overstated by an unknown amount that varies month to month.

All Quiet captures every incident from alert through acknowledgement to resolution automatically, so failure counts and operational time come from what actually happened rather than from what someone remembered to file. Because the same record drives paging, status pages and post-incident review, the failure count behind your MTBF is the same failure count your customers experienced.

That makes MTBF something you can read from your incident management software rather than reconstruct by hand at the end of a quarter — and a reliability metric that is reconstructed by hand is one nobody trusts enough to act on.