Ask a plant manager what an hour of downtime costs and you will get an answer immediately. Ask where the number came from and the room goes quiet.
This matters more than it sounds. The downtime figure is the denominator in every technology investment argument a manufacturer makes. If it is soft, every business case built on it is soft, and finance is right to discount it.
The number most people quote is the wrong one
The common calculation is lost production multiplied by unit margin. It is a floor, not a total, and it usually understates by a wide margin because it omits the costs that arrive later.
A more defensible figure has four parts.
Lost throughput, valued properly. If the line runs at capacity and the order book is full, an hour lost is an hour never recovered and the margin is gone. If you can catch up on overtime, the cost is the overtime premium, not the margin. Those are very different numbers and using the wrong one is the fastest way to lose credibility with your CFO.
Fixed cost absorption. The plant costs the same to run whether it is producing or not. Labour standing idle, depreciation, energy on equipment that must stay warm.
Recovery cost. Overtime, expedited freight to protect a delivery date, scrap and rework from an interrupted process, and the engineering hours that go into restarting rather than improving.
Customer consequence. The hardest to quantify and often the largest. A missed shipment against an OTIF commitment can carry a chargeback. A repeat failure can cost a programme award, and that is a multi-year number.
Frequency beats severity in the business case
The instinctive framing is the catastrophe: what if we lost a week. It is emotionally compelling and it is usually the weaker argument, because everyone in the room privately assigns it a low probability.
The stronger case is accumulation. Six unplanned stoppages a quarter, averaging ninety minutes, is a number people recognise from their own week. Multiplied out over a year against a defensible hourly figure, it is frequently larger than the catastrophe scenario and infinitely more credible, because everyone present has lived it.
Track the small ones. They fund the work.
Attribute causes honestly
The next question finance will ask is what share of that downtime technology can actually address, and the honest answer is never all of it.
Mechanical failure, material problems and changeover inefficiency are not IT problems. But when you categorise a year of stoppages you almost always find a tail that is: the network segment that drops, the server that runs the historian, the licence that expired, the integration that silently stopped writing.
That tail is the addressable number, and quoting it rather than the total is what makes the case survive scrutiny. A technology request that claims credit for mechanical downtime gets discounted entirely. One that says "of the 214 hours we lost last year, 38 trace to systems, and here is what those cost" gets funded.
Then make it recur
Having built the number once, keep it. A downtime log with causes attributed, reviewed quarterly, turns every subsequent investment conversation from an argument into an arithmetic problem.
It also does something useful in the other direction: it tells you when a proposed investment is not worth making, which is a finding worth having before the money is spent.