> ## Documentation Index
> Fetch the complete documentation index at: https://docs.rootly.com/llms.txt
> Use this file to discover all available pages before exploring further.

# What Is MTBF? Mean Time Between Failures Explained

> MTBF (mean time between failures) is the average operating time between failures. Formula, examples, and how it relates to MTTR and availability.

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?

```text theme={null}
MTBF = Total operating (up) time / Number of failures
```

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](/glossary/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:

```text theme={null}
Availability = MTBF / (MTBF + MTTR)
```

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:

| Metric       | Value                                                 |
| ------------ | ----------------------------------------------------- |
| MTBF         | 14,340 minutes                                        |
| MTTR         | 60 minutes                                            |
| Availability | 14,340 / (14,340 + 60) = 14,340 / 14,400 = **99.58%** |

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](/glossary/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](/metrics/default-metrics) for the available measures and groupings.

## Related terms

* [MTTR (mean time to resolution)](/glossary/mttr)
* [Error budget](/glossary/error-budget)
* [SLA vs SLO vs SLI](/glossary/sla-vs-slo-vs-sli)

Browse the full [incident management glossary](/glossary).