What is MTBF? Meaning, formula and MTBF vs MTTR vs MTTF

MTBF stands for mean time between failures. It is the average time a repairable system runs between one failure and the next. A higher MTBF means failures are rarer. You calculate it by dividing the total operating time by the number of failures.

The term comes from hardware reliability, where it describes servers, disks and power supplies. Teams that run websites and APIs use the same idea: how many hours does the service stay up between outages? This guide gives the meaning, the formula with the arithmetic shown, the difference between MTBF, MTTR, MTTF and MTTD, and a way to measure MTBF from real monitoring data without fooling yourself.

MTBF meaning in plain words

MTBF answers one question: when this thing breaks, then gets fixed, how long does it usually run before it breaks again? A service with an MTBF of 700 hours fails about once a month. A service with an MTBF of 7 hours is in trouble.

Three points help you read the number correctly:

• It is for repairable systems. The system fails, you repair it, it runs again. For an item you throw away after one failure, the right metric is MTTF.
• It is an average. An MTBF of 100 hours does not mean a failure every 100 hours. Failures can come in bursts, for example after a bad deploy.
• It needs a clear definition of failure. A crash, a timeout, an HTTP 500 for more than a minute and a slow page are different failures. Decide first, then count.

Two conventions exist. Most reliability references, and incident-management guides such as Atlassian's, divide operating time by the number of failures, so repair time is not part of the number. Some references measure from the start of one failure to the start of the next, which adds the repair time (MTBF = MTTF + MTTR, the form on our MTBF glossary page). When repairs are short compared with the time between failures, the two give almost the same result. This guide uses the first convention, because the availability formula below needs it.

The MTBF formula, with a worked example

MTBF = total operating time / number of failures

Example: one API over 90 days
  Window:          90 days x 24 h = 2,160 hours
  Incident 1:      30 minutes
  Incident 2:      90 minutes
  Incident 3:      60 minutes
  Total downtime:  180 minutes = 3 hours
  Operating time:  2,160 - 3 = 2,157 hours
  Failures:        3

  MTBF = 2,157 / 3 = 719 hours (about 30 days)
  MTTR = 3 hours / 3 incidents = 1 hour

Counted from one failure start to the next instead, the same data gives 720 hours, because 2,160 hours divided by 3 failures is 720. The difference is exactly one MTTR, and that is why the two conventions agree when repairs are short.

The inputs are plain: a time window, and the start and end time of every outage. If you do not have those timestamps, you cannot compute MTBF. You can only guess it.

MTBF vs MTTR vs MTTF vs MTTD

The four metrics look alike and answer four different questions. MTBF is about frequency. MTTR is about duration. MTTF is about the life of something you replace. MTTD is about how long a failure goes unnoticed.

MTBF vs MTTF in one sentence: MTBF is for systems you repair, MTTF is for items you replace. A web service is repairable, so MTBF fits. A hard disk that you swap when it dies is an MTTF case. More detail on each term: MTTR, MTTF and MTTD.

MTBF and MTTR work as a pair. MTBF tells you how often you get hurt, MTTR tells you how long each injury lasts. Improving either one raises your uptime.

MTBF, availability and your uptime percent

In steady state, availability is the share of time a system is up, and it follows from the two numbers above:

Availability = MTBF / (MTBF + MTTR)

Same API:
  719 / (719 + 1) = 719 / 720 = 99.861%
  Check:  2,157 up hours / 2,160 total hours = 99.861%

A 99.9% target allows 2,160 x 0.001 = 2.16 hours of downtime in 90 days.
We had 3 hours, so we missed the target.

Halve every repair (15, 45 and 30 minutes = 1.5 hours of downtime):
  MTBF = 2,158.5 / 3 = 719.5 hours,  MTTR = 0.5 hours
  719.5 / (719.5 + 0.5) = 99.931%   -> target met

The last block shows why MTTR matters as much as MTBF. The same three incidents, repaired twice as fast, turned a missed 99.9% target into a met one, with no failure removed. The formula assumes failures and repairs are random and that the time you count as downtime is only unplanned repair. To see what a given percentage means in minutes, use the uptime calculator or the SLA calculator, and read what a good uptime SLA is.

How to measure MTBF for a website or API

1. Pick a window. 90 days is a common start. Fewer than about ten failures gives a number that swings wildly, so widen the window or say that the sample is small.
2. Define a failure. For example: the endpoint fails for two or more consecutive checks. A single blip is not an incident.
3. Take the start and end times from a monitor, not from memory. People round outages to "about an hour" and forget the short ones.
4. Decide how to treat planned maintenance. Most SLAs exclude it. Exclude it from both the failure count and the downtime, and report it separately. Be consistent from month to month.
5. Compute it. Operating hours divided by failures, as in the example. If there were no failures in the window, MTBF is not infinite. It is at least the length of the window.

Two things distort the result. False alarms count as failures, so every false incident drags MTBF down. Confirming a failure before it opens an incident, for example after consecutive failed checks, removes most of that noise. The check interval sets your precision: with 5-minute checks a short outage can be missed, and every start and end time is off by up to 5 minutes, which also moves MTTR. Shorter intervals give truer numbers.

Common mistakes

• Reading MTBF as a lifespan. A hardware vendor's MTBF of 100,000 hours describes a failure rate across many units. It does not promise one unit lasts 11 years.
• Averaging different services. A rock-solid billing API and a flaky internal tool in one average hide both stories. Compute MTBF per service.
• Counting every alert as a failure. Alerts and failures are not the same. Count confirmed incidents.
• Ignoring the trend. Releases change the failure rate. One number for a whole year hides a bad month. Plot it per month.
• Mixing the two conventions. Operating time per failure and start-to-start time differ by one MTTR. Pick one and write it down.

When MTBF is not the right metric

• You have very few failures. With two incidents a year, MTBF is a guess. Track downtime minutes and your error budget instead.
• Severity differs a lot. A 30-second blip and a 6-hour outage each count as one failure. Customer impact, such as downtime minutes, tells you more.
• You replace, not repair. Use MTTF for disks, batteries and similar parts.
• Your customers feel duration. If one long outage hurts more than many short ones, watch MTTR.

MTBF is a good summary for a dashboard and a poor tool for a single decision. Treat Atlassian's own warning the same way: these metrics are a baseline for better questions, not an answer.

Where monitoring data fits in

MTBF needs exact start and end times of outages. An uptime monitor records them. Uptrack checks every 30 seconds on every plan and opens an incident only after consecutive failed checks, so the incident list has clean start and resolve times, with few false alarms. One honest limit: Uptrack does not compute MTBF or show an MTBF figure today. You take the incident start and resolve times from the incident history and do the arithmetic above. See uptime monitoring for how checks and confirmation work.

MTBF questions