RESOURCES · GUIDE
The real cost of unplanned downtime, and how to model it.
Every vendor quotes an “average cost of downtime.” None of those numbers is yours. Here is how to model your own from data you already have — and why the biggest line item usually isn’t the stopped machine, it’s the time spent finding out why it stopped.
THE TRAP The “average cost of downtime” number is useless to you.
You have seen the figures — “$260,000 an hour,” “50% of manufacturers…”. They are averages across industries with wildly different margins, throughput and asset criticality. Quoting one to your CFO gets you nowhere, because the cost of downtime on your bottleneck line at full order book is nothing like the cost on a buffered upstream station. The number you can defend is the one you build from your own frequency, duration and margin. The good news: every input already exists in your systems.
THE MODEL Four inputs, and where each one lives.
A defensible cost of unplanned downtime for a given asset is, at its core: how often it stops × how long each stop lasts × what a lost hour is actually worth. The last term is where most estimates go wrong — it isn’t just idle labour, it’s lost throughput at your contribution margin, plus scrap and restart, when the line is the constraint.
- Stop frequencyfrom your CMMS — failure count per asset over a period. Already recorded on every work order.
- Duration (MTTR + wait)from the CMMS timestamps — but the honest figure includes the diagnosis and wait time, not just wrench time.
- Lost throughputfrom your MES or production historian — units not made while down, but only counted when the asset is the bottleneck.
- Value per unitfrom your ERP — contribution margin, not revenue, plus scrap and restart cost for the affected lot.
THE HIDDEN MAJORITY Most of a stoppage is diagnosis, not repair.
Break a typical unplanned stop into its parts and the repair itself is often the short part. The long part is finding out what went wrong: which alarm fired, what the machine was doing, whether it happened before, where the procedure is, which part to pull. When the answer is spread across a SCADA screen, a CMMS, an ERP and a shelf of manuals, that search can run to the better part of two hours before a tool is even picked up. Reduce that, and you reduce downtime without touching the reliability of the machine at all.
You can cut downtime two ways: make machines fail less, or make each failure shorter. The second is faster, cheaper, and mostly a data problem.
The MTTR lever
WHERE IT SHOWS UP OEE / TRS: downtime lives in Availability.
OEE (TRS in French) multiplies Availability × Performance × Quality. Unplanned stops hit the Availability term directly, and a long MTTR drags it down harder than the raw failure count suggests. This is why chasing OEE improvement through reliability projects alone plateaus: you are optimising how often you fail while ignoring how long each failure costs you. Shortening diagnosis moves Availability first — the fastest visible lever on the TRS your board already tracks.
| Reduce MTTR (find root cause faster) | Reduce MTBF (buy reliability) | |
|---|---|---|
| What you change | Time to diagnose & fix | Failure frequency |
| Typical cost | Connect existing data | Sensors, redesign, spares |
| Time to impact | Weeks | Months to years |
| OEE term moved | Availability, immediately | Availability, eventually |
| Risk | Low — read-only, no asset change | Capital committed up front |
Both matter. Most plants underinvest in the first because the data to enable it is scattered.
A WORKED EXAMPLE Plug in your own numbers.
Illustrative only — replace every figure with yours. Say a bottleneck line stops on unplanned faults 4 times a month, ~90 minutes each, and when it’s down it fails to make 120 units/hour at a €25 contribution margin. That’s 4 × 1.5 × (120 × €25) = €18,000 a month in lost margin alone, before labour, scrap and restart — roughly €216,000 a year on one asset. Now suppose connecting the data cuts the diagnosis portion so average stops fall from 90 to 60 minutes. Same frequency, one third less duration: about €72,000 a year recovered, with no change to the machine. The point isn’t our number — it’s that your own inputs make this calculable, and defensible.
FAQ Questions on costing downtime.
- What is the cost of downtime?
- It’s the money an unplanned stop costs you — lost throughput at your contribution margin, plus labour, scrap and restart, over the stop’s duration and frequency. It’s asset-specific: the same minute of downtime costs far more on a bottleneck at full order book than on a buffered station.
- How do I calculate our cost of downtime?
- Per critical asset: stops per year × hours per stop × (lost units/hour × margin/unit + labour/hour) + scrap and restart. Stop frequency and duration come from your CMMS, lost throughput from the MES, and margin from the ERP — you already record all of it.
- What’s the difference between MTTR and MTBF?
- MTBF (mean time between failures) is how often an asset fails; MTTR (mean time to repair) is how long each failure takes to resolve — including diagnosis. Reducing MTTR is usually the faster, cheaper win because most of it is a search problem, not a spares problem.
- How does reducing downtime improve OEE / TRS?
- Unplanned stops hit the Availability term of OEE/TRS. Because a long MTTR lowers Availability more than the failure count alone implies, cutting diagnosis time moves OEE first — often the fastest visible improvement on the TRS you already report.
- How does AI actually reduce downtime?
- Not by magic prediction. By collapsing the diagnosis: AutomAssist connects your systems so the alarm, the machine state, the past fix and the procedure arrive as one answer instead of a six-system search — cutting MTTR, the largest and cheapest input to move.
Model it on your own line.
Bring one critical asset and its CMMS history — we’ll help you build a cost-of-downtime figure you can defend, and show where MTTR is hiding.
Book a demo