MTBF Calculation: How to Work Out Mean Time Between Failures

MTBF Calculation: How to Work Out Mean Time Between Failures

Ask three maintenance managers for the MTBF on a critical asset and you'll often get three different numbers for the same machine. Not because the arithmetic is hard — the formula fits on a beer mat — but because everyone counts the inputs differently. One uses calendar time, another uses running hours. One counts every callout as a failure, another only the ones that stopped production. Same equipment, wildly different figures.

MTBF calculation is only useful if the number means the same thing every time you produce it. This guide gives you the formula, a worked example you can copy, the difference between MTBF and its non-repairable cousin MTTF, and the mistakes that quietly corrupt the figure. It sits under our wider guide to maintenance KPIs — read that for how MTBF fits alongside MTTR, OEE, and the leading indicators that let you steer.

What MTBF Actually Measures

Mean Time Between Failures is the average amount of running time an asset clocks up between one failure and the next. It applies to repairable equipment — pumps, motors, conveyors, compressors, vehicles — the kind of thing that breaks, gets fixed, and goes back to work.

The word doing the heavy lifting is running. MTBF is a measure of reliability: how long the asset stays up while it's meant to be up. A rising MTBF is the clearest single sign your preventive programme is genuinely improving reliability rather than just burning hours. A falling one tells you a machine is heading for trouble long before anyone's written it off.

It's a lagging indicator — you're measuring failures that have already happened — so it won't tell you what breaks tomorrow. What it does, tracked per asset over time, is show you the trend and flag your bad actors.

The MTBF Calculation Formula

Here it is:

MTBF = Total operating time ÷ Number of failures

That's the whole thing. Total operating time is the hours the asset actually ran over the period you're measuring. Number of failures is how many times it failed and had to be repaired in that same window.

Two rules travel with the formula and both matter more than the division:

• Operating time, not calendar time. If a pump was installed for a year but only ran 4,000 hours, your denominator-side number is 4,000 — not 8,760. Give the asset credit only for the time it was working.
• Failures, not work orders. A failure is an unplanned stop that took the asset out of service. A scheduled oil change is not a failure. A cleaning task is not a failure. Mixing planned work into the count is the fastest way to make a healthy machine look unreliable.

A Worked Example

Take a single production pump, PUMP-07, over six months. You need two things: the hours it ran, and the number of times it failed.

Say it was scheduled to run two shifts a day, and after subtracting planned downtime, holidays, and the hours it sat idle waiting on upstream product, it clocked 4,180 running hours. Over that same period it suffered 5 unplanned failures — a seized bearing, two seal leaks, an impeller strike, and a motor trip. Each was fixed and the pump went back into service.

So PUMP-07 runs, on average, 836 hours between failures — roughly five weeks of two-shift operation. On its own that's just a number. Its value is comparison: against the same pump last quarter (is the trend up or down?), and against its sister pumps on the same duty. If PUMP-07 sits at 836 hours while PUMP-08 on identical duty sits at 2,100, you've found where to point your attention.

Note what we did not do: we didn't add the repair time, and we didn't count the two quarterly PM visits as failures. MTBF measures the gap between failures, not what happens during them — that's the job of MTTR, the sister metric that measures how fast you recover once something has broken.

MTBF vs MTTF: Repairable vs Non-Repairable

This is the distinction most people get wrong, and it's worth thirty seconds because using the wrong one produces a number that doesn't behave the way you think it does.

MTBF is for repairable assets. The item fails, you fix it, it carries on. You're measuring the average gap between failures across its working life — hence "between".

MTTF — Mean Time To Failure — is for non-repairable items. Things you replace rather than repair: light bulbs, sealed bearings, filters, batteries, fuses, most electronic modules. There's no "between" because the item only fails once, then it's binned. MTTF measures the average time to that single failure across a population of identical units.

The rule of thumb: if you repair it, use MTBF. If you replace it, use MTTF. A motor is MTBF. The bearing you swap inside that motor, tracked as a consumable, is MTTF. Get this wrong and you'll compare figures that were never measuring the same thing — a replaced-component lifespan against a repaired-asset uptime gap — and draw confident conclusions from nonsense.

The Mistakes That Quietly Wreck the Number

The formula never lies. The inputs do. Here are the four that corrupt MTBF most often, in roughly the order I see them.

1. Calendar time instead of running time. The single most common error, and CMMS reports are the worst offenders because it's easy to divide by "hours in the period" and move on. Crediting an asset with hours it wasn't running inflates MTBF and makes a marginal machine look robust. Always divide by actual operating hours.

2. Counting scheduled downtime as failures — or as uptime. Planned PM stops belong in neither pile. They're not failures (don't add them to the count) and they're not running time (don't include them in the hours). Fold them into the failure count and reliability looks terrible; count PM hours as running time and it looks artificially good. Strip planned work out of both sides entirely.

3. Tiny sample sizes. MTBF is an average, and an average of two or three events is barely an average at all. An asset that failed twice this quarter gives you an MTBF built on a sample of two — a single extra breakdown can halve it. Treat short-period, low-failure figures as directional at best; a first-quarter MTBF on a reliable machine is mostly noise.

4. Inconsistent definitions of "failure". If one technician logs a two-minute reset as a failure and another only logs jobs that needed parts, your MTBF measures your logging habits, not your equipment. Agree what counts as a failure — usually "an unplanned stop that took the asset out of service" — and hold the line. This is the same discipline that makes every other reliability metric trustworthy.

Each has the same signature: the arithmetic is fine, but the number moves for reasons that have nothing to do with the machine. Whenever an MTBF figure surprises you, check the inputs before you believe it.

Using MTBF Per Asset, Not Per Plant

A plant-wide MTBF is close to useless. Average the reliable machines together with the bad actors and you get a middling number that hides both. The reliable ones don't need attention and the number won't tell you which the troublesome ones are.

MTBF earns its keep at the asset level, on the equipment that matters. Calculate it per critical asset, track the trend, and rank. The assets with the lowest MTBF on the highest-consequence duty are your worklist — and consequence matters as much as frequency, which is why MTBF pairs naturally with a view of your riskiest assets, where likelihood meets what it costs when it goes. A machine that fails often but stops nothing is a nuisance; one that fails rarely but takes the line down each time is where reliability effort pays back.

Where the Data Has to Come From

None of this works without clean inputs, and that's the real barrier — not the maths. You need two numbers you can trust: honest running hours and an honest failure count. Both come from the same place — work orders closed properly and runtime captured against the asset.

If technicians close jobs from memory a week late, or "failure" means whatever the person filling in the form decided that day, no formula on top will be worth reading. MTBF is downstream of good record-keeping, not a substitute for it. A CMMS that logs runtime and failures against each asset as work happens turns MTBF into a report you pull in seconds, not a spreadsheet someone rebuilds each month and half-trusts.

If you're trying to get reliability metrics off spreadsheets and onto something that keeps its own inputs honest, book a call and we'll show you how teams set MTBF up per asset in AssetOS — usually with the trend on their critical equipment live within a week.