Your dashboard shows MTBF = 480 h on press #3. Friday, 2 p.m., your production manager calls you about the third stoppage this week. Someone is lying — and it isn't your team.
The 3 canonical industrial-maintenance KPIs — MTBF, MTTR, availability— are mathematically correct. Every CMMS on the market can compute them in seconds. The problem isn't the formula.
The problem is that those formulas run on uncleaned data, and they then produce operationally wrong numbers — numbers that end up in monthly reviews, in deferred CAPEX, in unreachable budget targets. In short: strategic decisions built on sand.
This article diagnoses 3 classic failure modes of maintenance KPIs, with field numbers to back each one, and gives a concrete fix for each — implementable without changing software.
Inflated MTBF: preventive and corrective mixed together
The most common lie — and the most invisible
MTBF (Mean Time Between Failures) = cumulative uptime / number of failures. The reference reliability metric for a repairable piece of equipment.
The trap
Most CMMS compute MTBF across every completed WO — preventive, corrective, inspections, everything that closes in the same bucket. The result: the more preventive maintenance you do (so the more mature you are), the higher your displayed MTBF climbs — without your equipment being any more reliable.
The preventive noise drowns the corrective signal. And the corrective signal is exactly what you're trying to measure.
An asset that fails every 2 months gets labeled “reliable” in the monthly review. Replacement CAPEX stays deferred year after year. The day the asset dies mid-critical-cycle, management discovers the lie — too late.
How to recompute (3 actions)
- Separate WO types at the data level. Preventive, corrective, improvement, inspection, emergency. The standard ISO 14224 §B.2 taxonomy works as-is (FreeMaint exposes 7 types by default).
- Filter the calculation.
MTBF = uptime / count(WO WHERE maintenance_type IN ('CORRECTIVE', 'EMERGENCY')) - Distinguish functional vs potential failure. A preventive job that catches degradation before the breakdown is not a failure — counting it as one defeats the very purpose of the inspection.
Understated MTTR: the blast radius of cascading stoppages
When the real cost of a failure is invisible in the KPI
MTTR (Mean Time To Repair) = average time between WO open and WO completion. Often confused with active repair time (the time actually spent repairing).
The trap
MTTR measures the repair of the failed equipment. But a failure almost always creates a blast radius: machine X goes down, line Y stalls downstream, material Z degrades while waiting, the crew sits idle. MTTR on X's WO captures none of it.
The hourly failure cost computed from MTTR ($/h × 2 h = $600) is ridiculously undervalued. No business case to invest in reliability because “it costs nothing”. The real cost (lost production + material + crew = ~$9,600) stays invisible — and management refuses reliability budgets because the KPIs don't justify the spend.
How to recompute (3 actions)
- Model the blast radius. Create a “Shutdown” or “Parent incident” object that groups the child WOs triggered by the cascade. Most modern CMMS allow this via a
parent_shutdown_idorincident_idfield. - Compute MTTR on the parent.
downtime = closed_at(parent) − opened_at(parent), not the sum of the child MTTRs. - Separate active repair time from downtime. ISO 14224 §3.13 has made that distinction for 30 years. Your reports should show them side by side — not the same number.
Inflated availability: the uncounted micro-stops
1 point of OEE lost in the statistical fog
Availability = Uptime / (Uptime + Downtime). At the heart of OEE (Overall Equipment Effectiveness) = Availability × Performance × Quality.
The trap
Availability only counts downtime logged through a WO. But on a typical production line, ~60% of stoppages are micro-stops under 15 minutes: jams, adjustments, purges, minor blockages, material waits, small format changeovers.
Those stoppages generate no WO because the operator clears them in 5 minutes without telling anyone. The result: invisible in the CMMS, invisible in availability, invisible in OEE.
↑ What the CMMS believes. What management sees. What serves as the OEE budget baseline.
On a plant doing $50M in revenue, 1 point of OEE lost = ~$500K of margin gone in the statistical fog. And the budgeted OEE target is unreachable because the baseline is wrong.
How to recompute (3 actions)
- Instrument the micro-stops. A
stop_countcounter on the asset, incremented on every stop >5 seconds via SCADA, PLC, or presence sensor. That's the first brick of serious downtime tracking. - Aggregate into time-buckets. Not one WO per micro-stop (unsustainable admin overhead), but hourly/daily buckets via meter readings in the CMMS. One meter row per day is enough.
- Separate 3 categories. Breakdown (>1h, opens a WO) — Short stop (15-60 min, logged without a WO) — Minor stoppage(<15 min, aggregated counter). Each reported separately in the dashboard.
Summary table — print it for your next steering committee
The 3 failure modes, the 3 fixes, the 3 direct impacts.
| KPI | Classic flaw | Correct calculation | Boardroom impact |
|---|---|---|---|
| MTBF | PM + corrective mixed in the failure counter | maintenance_type ∈ {CORRECTIVE, EMERGENCY} | Hidden risk ×5 to ×10 |
| MTTR | WO start → complete only, ignores the blast radius | Model a parent shutdown + cascaded downtime | Failure cost ×3 to ×15 |
| Availability | Micro-stops <15 min never logged | Instrument via SCADA + aggregate as meter readings | OEE off by 1-3 points |
3 actions for your next monthly review
These 3 KPIs aren't bad. It's their configuration that lies. The good news: none of these fixes needs new software or a budget. Just a clean WO taxonomy, a parent shutdown object in your existing CMMS, and a cron that aggregates micro-stops from your SCADA.
Recompute MTBF on corrective work only
On one critical asset, recompute MTBF excluding preventive WOs. Compare with the displayed MTBF. The error factor will speak for itself.
Log the next incident with an incident_id
On the next non-routine stoppage, log not just the repair WO but also an incident identifier that groups every impacted WO. Compute the real downtime on that parent.
Ask your SCADA for this month's micro-stops
Ask your automation team for the count of micro-stops under 15 min last month. Compare to zero — what your CMMS believes. You're in for a surprise.
Go further
- ISO 14224:2016 — Petroleum, petrochemical and natural gas industries — Collection and exchange of reliability and maintenance data for equipment
- SEMI E10-0814 — Specification for Definition and Measurement of Equipment Reliability, Availability, and Maintainability (RAM)
- Nakajima (1988) — TPM: An Introduction — the historical reference on OEE decomposition and the six big losses
Do your maintenance KPIs tell the truth?
FreeMaint is a freemium CMMS (Core free for life, with no user or asset limits) that natively separates preventive and corrective work via the ISO 14224 taxonomy — and lets you audit every KPI.
Article by Melek Mehrez, founder of FreeMaint. See all articles.
Frequently asked questions
Why is my MTBF misleading?
MTBF (Mean Time Between Failures) computed across every completed work order mixes preventive and corrective work. The more PM jobs you do, the higher the displayed MTBF climbs — without your equipment being any more reliable. The fix: filter the calculation to only the CORRECTIVE or EMERGENCY work orders, in line with the ISO 14224 taxonomy.
What is the blast radius of a failure?
The blast radius is the full chain of cascading consequences of a failure: machine X goes down, line Y waits, material Z spoils, the crew is idle. MTTR computed on X's repair WO alone captures none of it. To measure the real cost, model a parent shutdown object that groups every impacted WO and compute MTTR on that parent.
Why is my displayed availability wrong?
Availability only counts downtime logged in the CMMS through a work order. But ~60% of industrial stoppages are micro-stops under 15 minutes (jams, adjustments, purges, minor blockages) that the operator clears in 5 minutes without opening a WO. Those invisible minutes artificially inflate the displayed availability by 1 to 3 points on OEE.
How do I fix my KPIs without changing software?
None of the 3 fixes needs new software: (1) add a maintenance_type field on your WOs to separate preventive / corrective / emergency, (2) introduce an incident_id field to group the WOs of one blast radius, (3) instrument the micro-stops via your SCADA and aggregate via meter readings. All inside your existing CMMS.