Mean Time Between Failures: Formula, Worked Examples, and 6 Common Mistakes

The mean time between failures measures how much operating time a repairable asset delivers per failure over a chosen period. It helps maintenance teams spot frequent breakdowns and compare similar equipment. However, it does not tell you exactly when the next fault will happen.

This guide explains the MTBF formula, walks through single-asset and fleet examples, and shows how to build a reliable failure log. It also covers six common mistakes, the difference between MTBF and repair time, and a review process that turns a number into a useful maintenance decision.

What mean time between failures actually means

MTBF describes failure frequency through an average amount of operating time. You calculate it for equipment that can return to use after repair. For example, a repairable pump can fail, receive a fix, and run again.

IBM’s overview of MTBF explains the basic measure and its limits. A calculated average does not promise a fault-free life of that length. Therefore, treat it as a summary of evidence rather than a countdown.

Define what counts as a failure before collecting data. A loss of required output may count even when the machine still runs. In contrast, a routine adjustment may not count if the asset continues to meet its required function.

The definition should match the asset’s purpose. A cooling unit might fail to hold the required temperature while its fan still works. Thus, a simple “motor stopped” rule could miss the service loss that matters.

The MTBF formula

MTBF = total operating time during the observation period ÷ number of failures during that period.

Use the same scope for the hours and the failure count. If you count failures for one pump, use that pump’s operating hours. Also, keep every time value in the same unit.

Operating hours differ from calendar hours. A machine that runs one shift each day does not operate for every hour of the month. Therefore, use meter readings, verified run logs, or a clear estimate with an accuracy note.

A single-asset example

Suppose a fictional pump records 900 operating hours and three qualifying failures in one period. The MTBF formula gives 900 ÷ 3 = 300 operating hours per failure. This result summarizes that period alone.

One fault may occur after 40 hours and another after a much longer run. The average does not remove that variation. Next, read the fault descriptions to understand whether the events share a cause.

A fleet example

Consider three similar pumps with the same failure rule. Pump A runs for 600 hours with two failures, Pump B runs for 300 hours with one failure, and Pump C runs for 900 hours with three failures.

The pooled MTBF is 1,800 ÷ 6 = 300 hours. Add the hours and failures before dividing. Do not simply average asset-level MTBF values when the assets have different exposure or failure counts.

Only pool assets when the grouping makes sense. Different loads, designs, or duty cycles can make a combined number hard to interpret. In that case, show separate groups and explain the difference.

MTBF, MTTR, and MTTF answer different questions

MTBF asks how often a repairable asset fails relative to its time in use. Mean time to repair asks how long repairs take under your chosen clock. Meanwhile, mean time to failure often describes items that do not return to use after a repair.

IBM’s comparison of MTTR and MTBF separates these measures. A team can repair faults quickly while the same asset still fails too often. Therefore, track failure frequency and restoration time together when both affect service.

Consider two hypothetical units. One fails often but takes little time to restore; another rarely fails but needs a long specialist repair. Their maintenance needs differ even if a broad downtime report looks similar.

A system for asset maintenance records can connect these views. Keep the run history, failure event, and repair record linked to one asset. This makes it easier to trace a metric back to real work.

Create a failure log that supports the calculation

Start with an asset list that uses stable IDs. Record the model, installation context, duty, and relevant meter type. Also, identify the service function that the asset must provide.

For each event, capture the failure time, meter reading, observed symptom, effect on service, and repair reference. Next, add the confirmed cause when the team has evidence. Keep an unknown cause marked as unknown rather than forcing a guess.

Link multiple visits for the same unresolved fault. A return visit may reflect an incomplete repair rather than a fresh failure. However, once the asset has passed your return-to-service check, a later qualifying fault may count as a new event.

Use computerized maintenance management to organize this history when the workload grows. Before relying on a report, check how the platform treats cancelled work orders, duplicate requests, and reopened jobs.

Document meter changes as well. A replacement meter may restart at zero and create a false drop in operating time. Store the old reading, new reading, change date, and adjustment rule.

Six common MTBF mistakes

1. Counting time when the asset does not run

Using all calendar hours can inflate the denominator for intermittent equipment. Instead, use actual run time where you can. If you estimate, record the method so the next report follows the same rule.

Meter quality also matters. Check whether a meter counts power-on time or actual operation. Those values can differ when equipment sits idle while connected to power.

2. Treating every work order as a failure

Work orders can describe inspections, planned tasks, upgrades, and faults. Therefore, a work order count does not automatically equal a failure count. Add an event type and review unclear cases.

Similarly, one outage can create several work orders for different trades. Count the event at the scope you defined. Keep the linked jobs for cost and repair analysis.

3. Presenting zero failures as infinite reliability

When no failures occur, you cannot produce a finite observed MTBF with the simple division. Report the operating exposure and “zero observed failures” instead. That statement preserves what you know without claiming endless service.

A short failure-free period provides less evidence than a long one. Thus, always display the observation period and operating hours. Readers should see the sample behind the result.

4. Comparing unlike assets

A pump that handles a harsh fluid and a pump that handles clean water face different work conditions. A higher MTBF in one group does not prove better maintenance. First, check load, age, operating mode, and service demands.

Use meaningful asset groups, then inspect differences within each group. A small number of troublesome units can hide inside a large fleet average. Keep an asset-level view available.

5. Using the average as a replacement date

A 300-hour MTBF does not mean that every unit should receive a replacement at hour 299. Failures do not follow one fixed schedule just because the average has a value. Instead, combine history with condition, known failure mechanisms, and approved maintenance guidance.

Where a fault carries serious consequences, involve the people responsible for engineering and site safety decisions. A dashboard should support their review. It should not automatically extend an inspection or service interval.

6. Ignoring how the data changed

A new reporting process may capture faults that the old process missed. The MTBF can fall even though equipment performance has not worsened. Therefore, mark changes to failure definitions, meters, and reporting coverage.

Keep the original record and a visible correction trail. If someone removes a duplicate, record the reason. This makes month-to-month comparisons easier to explain.

How to use the result in maintenance planning

Start with repeat failures that affect service most. Read the event notes and compare parts, conditions, and repair actions. Next, ask whether the failure stems from wear, use, installation, or an unresolved underlying problem.

A falling MTBF calls for investigation, not an automatic increase in every service task. Some failures may not respond to more frequent routine work. Our guide to industrial preventive maintenance software explains how teams organize tasks once they choose the right response.

Assign a specific action to each useful finding. For example, check whether a repeated seal fault follows a change in duty. Then record the review outcome and the reason for any change to the plan.

After the change, compare a new period with similar exposure. Keep the sample size visible and allow enough time for a useful comparison. One quiet week does not establish a durable improvement.

Build a report that leads to action

A useful report shows the asset group, period, operating hours, failure count, definition, and MTBF. Add downtime or cost only when those fields help prioritize the response. In addition, give readers a route to the underlying events.

Use a custom reporting system when your run-hour and repair records sit in different tools. Match records with stable asset IDs, not display names alone. Check failed imports and late updates before refreshing the published report.

Keep the report version with the period it describes. Otherwise, a later correction can change last month’s figure without explanation. A short note can state what changed and why.

A practical review routine

Each week, review new failure records for missing asset IDs, duplicate events, and meter errors. Then check open faults that still await a clear outcome. This keeps the calculation from becoming a month-end cleanup task.

Each reporting period, compare related asset groups and review the most costly repeat issues. Keep a short action register with the owner, next step, and due date. Also, revisit old actions to see whether they changed the failure pattern.

For a newly added asset, show its limited history clearly. Avoid ranking it against units with years of exposure as though the evidence were equal. Over time, the record can support more useful comparisons.

Check the numerator and denominator separately

Before releasing a report, select a few assets and reconcile their operating hours with the source meters. First, confirm the start and end readings. Then check meter resets, replacement dates, and any periods that your definition excludes.

Next, inspect the failure list independently. Each event should describe a loss of the required function, not merely a request for work. Link duplicate requests and preserve the decision that removes an event from the count.

For a pooled group, compare the summed hours with the asset roster for that period. A retired asset can still contribute valid exposure before its removal. Meanwhile, a newly added asset should contribute only the hours that belong to the chosen scope.

This separate check makes errors easier to locate. If the ratio changes sharply, you can see whether hours, failure counts, or both caused the change. Keep a short reconciliation note with the published period so another reviewer can reproduce the result.

Turn failure history into a better maintenance question

The mean time between failures helps you ask which assets fail too often for their role. Use consistent run hours, a clear failure rule, and traceable events. Then investigate the cause and review the effect of each maintenance change.