The bottom line
Three reliability metrics turn breakdown anecdotes into decisions. MTBF (mean time between failures) = operating time / number of failures — how reliable a machine is. MTTR (mean time to repair) = total repair time / number of repairs — how fast you recover when it fails. Availability = MTBF / (MTBF + MTTR), the share of needed time the machine is actually able to run. Together they separate two different problems: a low MTBF is a reliability problem (fix the failures), a high MTTR is a response problem (fix the repair process), and they call for different action. They fall out of maintenance records (failures, repair durations) joined to production records (run hours) — data a manufacturing ERP already holds. Where it breaks: the metrics are only as good as the capture discipline, and a fleet average hides the problem machine, so you calculate them per asset.
In This Article
Everyone knows the problem machine — nobody can prove it
Ask any shop floor which asset causes the most grief and you will get an instant, confident answer. Ask for the number that proves it, and the room goes quiet — because the failures are recorded in a maintenance logbook or CMMS, the run hours sit in production, and nobody joins them. Maintenance budgets, replace-or-repair decisions and shift planning then get made on reputation and the loudest supervisor rather than evidence.
MTTR, MTBF and availability are the standard reliability metrics that convert that shared intuition into defensible numbers. They are not exotic — the formulas are simple arithmetic — and the data they need is already being collected by any manufacturer running a maintenance process and a production system. The gap is almost never the maths; it is joining maintenance and production data cleanly and capturing the events with enough discipline to trust the result.
MTBF: how reliable the machine is
Mean time between failures is operating time divided by the number of failures over a period. If a machine ran 900 hours and failed three times, its MTBF is 300 hours — on average it runs 300 hours between breakdowns. It measures inherent reliability: a high MTBF means the machine rarely fails, a low MTBF means it fails often, independent of how quickly you fix it.
MTBF is the metric for reliability decisions — which assets are genuinely unreliable, whether a refurbishment or replacement is justified, and whether a preventive-maintenance regime is reducing failure frequency over time. Tracked per asset and trended, a falling MTBF is an early warning that a machine is degrading before it fails catastrophically, which is the hook into condition-based and predictive maintenance. It answers 'how often does this break', and that is the first half of the reliability picture.
MTTR: how fast you recover when it fails
Mean time to repair is total repair time divided by the number of repairs. If three breakdowns took 2, 4 and 3 hours to fix, MTTR is 3 hours — on average a failure costs three hours of downtime to restore. It measures the maintenance response, not the machine: how quickly the team detects, diagnoses, sources parts for, and completes a repair.
A high MTTR points at the repair process rather than the machine — slow fault diagnosis, waiting for spare parts, waiting for a technician, poor documentation. Two machines can have identical failure rates but very different downtime impact because one is restored in an hour and the other in a shift, and only MTTR exposes that. It is also the metric most improvable by organisation rather than capital: better spares holding, clearer fault procedures and faster response cut MTTR without touching the machine.
MTBF is about the machine; MTTR is about the maintenance process. A machine can be unreliable (low MTBF) or just slow to fix (high MTTR) — and the two call for completely different responses, which is why you need both numbers, not one.
Availability ties reliability and response together
Availability is MTBF divided by (MTBF + MTTR) — the proportion of the time it is needed that a machine is actually able to run. It combines the two: a machine with a 300-hour MTBF and a 3-hour MTTR has an availability of 300 / 303, about 99%. It is the single number that expresses the net effect of both how often a machine fails and how long it takes to recover, which is why it feeds directly into OEE as the availability component.
Availability is the headline for operations because it maps to capacity: lost availability is lost production capability. But it must be read alongside its two drivers, because the same availability figure can come from frequent-but-fast failures or rare-but-slow ones, and those are different problems. Availability tells you how much you are losing; MTBF and MTTR tell you why, and therefore what to do about it.
Two metrics, two different fixes
The practical power of having both MTBF and MTTR is that they separate two problems that a single downtime figure conflates. A machine with a low MTBF has a reliability problem — it breaks too often — and the response is engineering: root-cause the recurring failures, refurbish or replace, strengthen preventive maintenance. A machine with a high MTTR has a response problem — it takes too long to fix — and the response is operational: spares strategy, fault procedures, technician availability, documentation.
Confusing the two wastes money. Buying a new machine to fix what is actually a slow-repair problem solves nothing; drilling the maintenance team on faster repairs does not help a machine that is simply worn out. The two numbers point at the right lever, and tracked per asset they let a maintenance manager allocate a limited budget to the assets and the problems where it will actually move availability — which is the whole point of measuring.
Where this breaks
The metrics are only as good as the event capture. If breakdowns are logged inconsistently, repair start and end times are estimated after the fact, or minor stoppages go unrecorded, the MTBF and MTTR are built on sand and will mislead. Capture discipline — recording every failure, with real start and end times, against the specific asset — is the prerequisite, and it is usually the weakest link because it depends on people on a busy floor logging events honestly and promptly.
A fleet or line average hides the problem machine, which defeats the purpose — the whole value is per-asset, so calculating a plant-wide MTBF tells you little. Definitions also have to be consistent: what counts as a failure versus a minor stoppage, and whether repair time includes waiting for parts, must be defined once and applied uniformly, or comparisons between assets are meaningless. And the metrics describe the past — they guide where to act, but turning a falling MTBF into a prevented failure is the separate step of condition-based or predictive maintenance.
What to do first
Get clean capture against each asset, then calculate per machine.
- Define consistently what counts as a failure, and whether repair time includes diagnosis and parts waiting — apply it uniformly
- Capture every breakdown with real start and end times against the specific asset, in the CMMS or ERP maintenance module
- Join maintenance records (failures, repair durations) to production records (operating hours) — the common gap
- Calculate MTBF, MTTR and availability per asset, not as a fleet average, and trend them over time
- Use the split to direct action: low MTBF to engineering/reliability, high MTTR to the repair process and spares
If you know which machine is the problem but can't prove it with a number, MTTR, MTBF and availability are already in your maintenance and production data waiting to be joined. Book 30 minutes with Amit on machine reliability metrics from your ERP and CMMS. No slides, no pitch deck, no obligation to proceed.
Free Assessment
Where does your operation sit on the data maturity curve?
8 questions. 3 minutes. You get a scored breakdown across data infrastructure, analytics readiness, and automation potential — with a specific next step for your industry.