Every maintenance team eventually gets asked some version of the same question: is our equipment getting more or less reliable? MTTR, MTBF, and availability are the three numbers built to answer that, and unlike a lot of maintenance metrics, they're simple enough to calculate on a whiteboard — the hard part is making sure you're measuring the right thing, and knowing which lever actually moves each one.
MTBF — Mean Time Between Failures
MTBF measures how long an asset runs, on average, before it fails. The formula is straightforward:
MTBF = Total operating time ÷ Number of failures
If a pump ran for 4,000 hours across a quarter and failed 4 times, its MTBF is 1,000 hours. A higher MTBF means a more reliable asset — it's failing less often relative to how much it's actually running. MTBF is an uptime metric: it only counts the hours the asset was actually operating, not the hours it sat idle or was already down for repair.
MTTR — Mean Time to Repair
MTTR measures how long it takes to get a failed asset back into service. The formula is the mirror image of MTBF:
MTTR = Total repair time ÷ Number of repairs
If the same pump's 4 failures took a combined 8 hours to fix, its MTTR is 2 hours. A lower MTTR means faster recovery — the team is diagnosing and fixing problems quickly once they happen. MTTR is a downtime metric: it only counts the hours the asset was actively being repaired, from the moment work started to the moment it was handed back.
Availability — the number that combines both
MTBF and MTTR each tell half the story on their own. Availability combines them into a single figure that answers the question people actually care about: what percentage of the time is this asset ready to run?
Availability = MTBF ÷ (MTBF + MTTR)
Using the numbers above: 1,000 ÷ (1,000 + 2) = 99.8% availability. That's a useful sanity check on its own — an asset can have an impressive MTBF and still lose meaningful availability if its MTTR is high enough, and a plant with modest MTBF can still run a highly available line if the team resolves failures fast.
What actually moves these numbers
Tracking MTTR and MTBF is easy. Improving them requires pulling different levers, because they respond to different things:
- MTBF improves through preventive maintenance, condition monitoring, and root-cause analysis on repeat failures — you're extending the time between problems, not reacting faster to them
- MTTR improves through faster diagnosis, better spare-parts availability at the point of failure, and clear repair procedures technicians can follow without hunting for information — you're shrinking the repair itself
- Both improve when failure data is actually captured consistently — you cannot improve either number using data that's incomplete or inconsistently logged
A common mistake is treating MTTR as the priority metric because it's the more visible pain point — a line is down, everyone is watching the clock. But a plant that only invests in faster repairs while ignoring MTBF is optimizing for firefighting, not reliability. The bigger long-term win is almost always on the MTBF side: every failure prevented is one that never needed an MTTR clock started at all.
Mistakes that quietly wreck both numbers
The formulas are simple enough that most of the real error happens in what gets counted, not in the arithmetic. A few mistakes show up often enough to watch for specifically:
- Counting calendar time instead of operating time in MTBF — if a line runs two shifts, not three, using 24-hour calendar time inflates MTBF and makes the asset look more reliable than it is
- Letting wait-for-parts time bleed into MTTR — the clock on a repair should start when work actually begins, not when the failure occurred; if a part takes two days to arrive before repair even starts, that's a supply-chain problem, not a repair-speed problem, and blending the two hides which one actually needs fixing
- Inconsistent failure definitions — if one technician logs every minor stoppage as a "failure" and another only logs full breakdowns, the resulting MTBF is comparing two different things across the same asset
- Small sample sizes — an asset with only one or two failures in the period being measured can swing wildly month to month; MTBF becomes meaningful once there's enough failure history to average out noise, not after a single event
None of these are exotic edge cases — they're the normal way these numbers drift when they're being tracked by hand across different people and different shifts. The fix isn't more discipline, it's a system that enforces one consistent definition of "failure start" and "repair start" for everyone logging data.
Putting availability in context
Once availability is calculated, the harder question is what to compare it against. There's no single universal target — a batch chemical process running at 95% availability might be performing exceptionally well, while a continuous packaging line at the same 95% could be leaving real money on the table, because the cost of each point of downtime is completely different between the two. The more useful comparison is almost always an asset against its own trend line: is this month's availability better or worse than last quarter's, and if it moved, which of MTBF or MTTR actually drove the change.
Getting started without a data-science project
None of this requires sophisticated statistics to start. The minimum viable version is logging two timestamps per failure — when the asset went down and when it came back up — plus a short failure-cause note, consistently, for every event. Even that basic data set, tracked for a single quarter across your critical assets, is enough to calculate real MTBF and MTTR figures and start seeing which equipment actually deserves the next round of reliability investment, rather than guessing based on whoever complained most recently.