Downtime Cost Calculation: Putting a Dollar on Lost Hours
The supervisor tells you press #3 was down four hours yesterday. You nod, write it in the log, and move on — because "four hours down" doesn't tell you anything you can act on. Was that a $40 problem or a $4,000 problem? Should you fix the tooling fixture that keeps binding, or is that four hours actually the cheapest machine in the building sitting idle while the expensive one ran fine? Without a dollar figure attached, every downtime hour looks the same on the page, and the ones that matter most get buried next to the ones that don't.
This is the gap between tracking downtime and costing it. Most shops that log downtime at all stop at the hour count — a tally by shift, maybe a reason noted in the margin of a traveler. That's a start, but it's not a management tool yet. A downtime cost calculation turns that same hour count into a number you can rank, compare across work centers, and defend in a customer conversation about a late job. This article walks through the formula, a worked example, and how reason codes turn a single total into a priority list.
The formula: rate times hours, work center by work center
The mechanism is simple on paper. Downtime cost equals the work center's burden rate multiplied by the hours it sat idle:
Downtime cost = work-center rate ($/hr) × downtime hours
The entire calculation lives or dies on that rate. A work-center rate isn't just the operator's wage — it's the fully loaded cost of that station sitting there ready to run, whether it's producing parts or not: labor, the machine's depreciation and maintenance allocation, floor space, utilities, and any other overhead you assign to that center. If you haven't built one, that's the actual first step — see our guide to work-center rate calculation for the mechanics of rolling burden into a per-hour figure per machine or cell.
Once you have that rate, downtime cost calculation stops being guesswork. A five-axis mill with a $145/hr loaded rate sitting idle for three hours is a very different number than a manual deburring bench at $28/hr sitting idle for the same three hours — even though both show up as "3 hours down" in a plain log. The rate is what separates a real cost figure from a hunch.
Why the hour count alone misleads you
Ranking downtime by hours alone systematically overweights whichever work centers run the most shifts or get logged the most diligently, and underweights your most expensive equipment if its operators are less consistent about noting downtime. A shop that only tracks hours will chase the wrong fires — fixing the annoying-but-cheap problem because it generates the most log entries, while the genuinely expensive bottleneck goes unaddressed because nobody attached a number to it.
A worked example
Say a CNC turning center has a loaded work-center rate of $85/hr. Over one week, the shop logs the following downtime, reason-coded rather than lumped together:
- Setup and changeover: 6 hours
- Waiting on material: 3 hours
- Unplanned rework of the causing operation: 2 hours
- Waiting on a fixture from another job: 1.5 hours
Total downtime: 12.5 hours. At $85/hr, that's $1,062.50 for the week on that single machine — illustrative for a representative shop, not a claim about any particular one. Run the same math on a second work center at $52/hr with 9 hours logged, and the dollar total ($468) is actually lower than the first machine's, even though the hour count looks closer. Without the rate applied, a manager glancing at raw hours might prioritize the second machine's downtime over the first's — backwards from where the money actually is.
This is the whole case for doing the multiplication rather than eyeballing the hour tally. It costs nothing extra to calculate once you already have the rate and the logged hours — the only real investment is capturing downtime with enough consistency, at the work-center level, to make the arithmetic mean something.
Reason codes turn the total into a priority list
A single downtime cost figure per work center is useful for a monthly report. It's not useful for deciding what to fix first. That's what reason codes are for — tagging each downtime entry with why the machine was down (setup, waiting on material, waiting on a fixture, unplanned rework, maintenance) so the dollar total can be broken apart by cause, not just by machine.
Go back to the turning center above: $1,062.50 in downtime cost for the week sounds like one problem. Broken out by reason code, it's four different problems with four different owners — setup and changeover is a scheduling and tooling-prep issue, waiting on material is a purchasing or receiving issue, waiting on a fixture is a shared-resource conflict between jobs, and rework traces back to whichever operation caused the defect. Each of those gets fixed by a different person, with a different fix. A single downtime total tells you nothing about who should be in the room. A reason-coded breakdown tells you exactly that. For a deeper walkthrough of setting up and standardizing reason codes across a shop, see our piece on downtime reason codes in manufacturing.
Downtime cost vs. OEE — different questions, same raw data
Shops that have looked into Overall Equipment Effectiveness sometimes assume OEE already answers this. It doesn't, not directly. OEE expresses downtime as a percentage — availability lost against a theoretical maximum — which is genuinely useful for benchmarking a machine's performance over time. But a percentage doesn't tell you what a specific week of downtime cost the business, and it doesn't attribute that cost to a job, a customer order, or a reason you can act on this afternoon. Downtime cost calculation and OEE are answering related but distinct questions from the same underlying data — one is a performance ratio, the other is a dollar figure tied to a cause. We cover the distinction in more detail, including where each metric earns its place in a small shop's reporting, in OEE vs. job costing.
Putting this into your own numbers
None of this requires new software to start — a spreadsheet with a rate column, an hours column, and a reason-code column will get you a first pass this week. The friction shows up at scale: once downtime is logged across a dozen work centers and multiple shifts, keeping the reason codes consistent, the rates current, and the totals rolled up by cause instead of by machine becomes a manual-entry problem rather than a math problem.
That's the layer WorkTickets handles directly. Downtime is logged against the operation that's actually running (or not running) at the moment, tagged with a reason code — setup, run, waiting, rework — right from the clock-in screen, and rolled up against the work-center rate you've configured for burden and machine cost. The result is the same calculation shown above, produced automatically instead of reconstructed at month-end from a paper log.
If you want to run this calculation on your own numbers before deciding whether to automate it, our Downtime & Reason-Code Analysis Workbook is built for exactly that — a template for logging downtime by reason code, applying your own work-center rates, and seeing which machine and which cause are actually costing you the most. For the broader picture of how downtime costing fits into routing, traveler, and actual-vs-quoted tracking end to end, our small job shop execution and costing guide and our piece on machine downtime analysis are the next stops.
