What unplanned downtime really costs in 2026, with sources.
Every article quotes a different cost of downtime, and most of them trace back to the same recycled estimate. Here are the numbers that hold up, where each one comes from, and how to price an hour of downtime at your own plant.
Ask three vendors what unplanned downtime costs and you will get three confident, incompatible numbers. That is not because the question is unanswerable. It is because most articles quote each other instead of a source. This post collects the figures that actually hold up, names where every one of them comes from, and shows how to turn them into a number for your own line.
How much does unplanned downtime cost per hour?
The most rigorous recent public dataset is Siemens’ True Cost of Downtime report (2024), built from surveys of large manufacturers across industries. It puts the cost of one hour of unplanned downtime between $36,000 in the lightest cases and $2.3 million per hour in automotive. The width of that range is the point: downtime cost is a function of your margin per unit, your line rate, and your labour structure, so any article quoting one universal number is already wrong.
| Metric | Value | Source |
|---|---|---|
| Cost of one downtime hour | $36k to $2.3M, by industry | Siemens, True Cost of Downtime, 2024 |
| Unplanned stops per plant | 25 per month | Siemens, 2024 |
| Downtime hours per plant | 27 per month | Siemens, 2024 |
| Mean time to repair (MTTR) | 65 minutes | Siemens, 2024 |
| Production capacity lost | about 5% | ARC Advisory Group |
| Loaded US labour cost | $46.60 per hour worked | US BLS, ECEC, March 2026 |
A note on the figure you have probably seen most often: roughly $260,000 per hour. It traces back to a single analyst survey from 2016, and it has been recycled for a decade, usually without the year, the sample, or the industry mix attached. It was a reasonable average then. Quoted as a universal constant in 2026, it is closer to folklore than data.
Where does the repair hour actually go?
Reliability engineering answered this long before anyone put AI in a press release. MIL-HDBK-472, the US military’s maintainability handbook, and IEC 60050-192, the international vocabulary for dependability, both split repair time into phases: detecting the fault, localizing it, correcting it, and checking the fix. Across both frameworks, hands-on correction is only 30 to 40 percent of the clock. The majority of every repair hour is spent working out what is wrong and confirming the theory.
The most expensive part of a breakdown is not fixing it. It is the time spent finding out what to fix.
That split is why two plants with identical machines and identical failure rates can have wildly different downtime bills. The plant that localizes faults in minutes pays for the repair. The plant that localizes faults by walking the panel with a laptop pays for the repair plus a diagnostic tax on every single stop, 25 times a month.
How do you price your own downtime hour?
Three components cover most of it. Lost throughput: units per hour times contribution margin per unit. Idled and responding labour: headcount times the loaded rate (the BLS average is $46.60 per hour worked, but use your own). Scrap and restart: whatever a stop destroys plus the ramp back to rate. Add them for one hour, multiply by your own monthly downtime hours, and you have a defensible number for the cost of doing nothing.
We built a free calculator that does this arithmetic with every default traceable to the sources above. Change any input and it recomputes; nothing about your plant is uploaded or stored.
Price your downtime hour with the free calculator →Why is MTTR the number to attack?
You cannot buy your way out of failures entirely; even excellent plants log unplanned stops. But the 65-minute average MTTR is not a law of physics. If 60 to 70 percent of it is detection, diagnosis, and verification, then the fastest lever on the whole downtime bill is fault localization, and that is a software problem: it depends on how quickly someone can see what the controller is doing and why. This is exactly the share that AI for PLC troubleshooting attacks, reading the full control logic and checking its reasoning against live values from the running controller, so the theory-building hour becomes minutes.
How runtime PLC data multiplies troubleshooting →PLCs.ai: AI for PLC troubleshooting, programming, and documentation →More from the blog

Six things every PLC engineer runs into, and how PLCs.ai finds them automatically.
Cycle-time bottlenecks, dead code, missing interlocks, broken handshakes, race conditions, and signal tracing. Plain-English explanations of concepts that usually take years on the floor to learn to spot.

How to reduce MTTR in manufacturing: fix the hour nobody measures.
The average plant repairs an unplanned stop in 65 minutes, and most of that hour is not repair at all. A practical playbook for cutting MTTR by attacking diagnosis, the phase most plants do not even measure.

PLCs.ai vs. pasting your PLC files into ChatGPT.
A general-purpose chatbot can read a snippet of ladder logic. It can't reason across your whole project, simulate a change before it goes live, or guarantee your PLC code never trains someone else's model.
