The Meeting Where Nobody Could Say Why the Mill Was Down
The quarter closes, and the numbers on the mill's utilization don't match anyone's memory of the floor. Everyone agrees it was busy — parts were moving, the supervisor was walking laps, the operator swears he never stopped. But the machine hours booked against jobs come in well under the hours the shop was open, and nobody in the room can point to a specific cause. Was it tooling changeovers? A vendor delivery that showed up late? Rework on a batch that got kicked back from inspection? Without a record, it's all plausible and none of it is provable.
This is the gap that swallows margin quietly, job after job, without ever showing up as a single dramatic loss. A machine that's "down" for reasons nobody logged is a machine whose true capacity nobody can plan around, and a job whose true cost nobody can defend at the next quote.
Machine downtime analysis exists to close that gap — not as an abstract manufacturing-engineering exercise, but as a floor-level habit: capture why a machine stopped, at the moment it stopped, in a small fixed set of categories, then roll those categories up until a pattern is undeniable. This article walks through how that works in practice, from the reason code an operator taps at the machine to the ranked list of cost drivers that shows up in a review meeting.
What Reason-Coded Downtime Data Actually Captures
Downtime analysis is only as useful as the reason codes underneath it. A raw "machine was idle for 45 minutes" tells you almost nothing actionable. A coded entry — setup, waiting on material, rework — tells you exactly where to look next.
The mechanism is simple: every time a machine or operation isn't producing good parts, that gap gets tagged with a reason at the point of occurrence, not reconstructed afterward from memory. In WorkTickets, this happens through the same clock-in/out flow an operator already uses to track a job — when the operator clocks off an operation or flags a stoppage, they select a downtime reason code rather than leaving it blank. That single tap is what turns an ordinary time log into an analyzable dataset.
The discipline matters more than the software. A shop running paper travelers can code downtime too, if the traveler has a field for it and the habit is enforced. What breaks most paper-based attempts is that the coding happens at end-of-day from memory, which means "waiting" and "setup" get conflated, rework gets absorbed into run time, and the resulting rollup is closer to guesswork than data. For a full breakdown of what a defensible reason-code taxonomy looks like on the floor, see our companion piece on downtime reason codes in manufacturing.
The Four Reason Codes That Matter Most
Most job shops don't need twenty categories. Four does most of the work:
- Setup — time spent configuring the machine, tooling, or fixture before production starts on an operation.
- Run — time actually cutting, welding, forming, or assembling (this is the baseline against which everything else is measured).
- Waiting — the machine or operator is idle for a reason outside the operation itself: material not staged, prior operation not finished, programming not ready, an approval pending.
- Rework — time spent correcting a part that didn't pass inspection or didn't meet spec the first time.
Keeping the list this short is deliberate. A reason-code taxonomy with too many options gets abandoned at the machine because nobody wants to scroll through fifteen choices under time pressure; a taxonomy this tight gets used consistently, and consistency is what makes the rollup meaningful. Machine downtime analysis built on inconsistent tagging is worse than no analysis at all, because it produces false confidence in a number that isn't real.
Rolling Coded Events Up by Work Center
A single coded downtime event is a data point. The analysis starts when those events get aggregated by work center over a meaningful window — a week, a month, a quarter — so that patterns separate themselves from noise.
The rollup itself is straightforward arithmetic: sum the minutes tagged to each reason code, per work center, per period. What makes it useful is presenting it as a live queue view rather than a static end-of-month report. WorkTickets' WIP dashboard defaults to exactly this — a work-center queue view that shows what's active and what's stalled, so a supervisor doesn't have to wait for a monthly report to notice that the deburring station has logged more waiting time than run time three weeks running.
Once the rollup exists, the "where is job X" question that used to require walking the floor becomes a search — by job, part, or customer — instead of a physical search party. That doesn't replace the reason-code discipline; it depends on it. A search only surfaces useful context if the events behind it were coded honestly in the first place.
From Downtime Minutes to Downtime Cost
Minutes of downtime are a starting point, not the finish line — they only matter once they're converted into a cost, because cost is what a quote decision or an equipment decision actually turns on.
Here's a worked example, illustrative for a representative shop, not a sourced industry figure: say a work center carries a burden rate — the combined cost of the machine, its floor space, and its overhead allocation — of $85/hour. If that work center logs 40 minutes of waiting downtime on a single job, the arithmetic is:
40 minutes ÷ 60 × $85/hour = $56.67 in burden cost consumed by that job without a single good part being produced.
Multiply that across every job that touches the same work center in a month, and a pattern that looked like an occasional annoyance turns into a specific dollar figure a shop can act on — renegotiate a material-delivery schedule, reassign a bottleneck operation, or simply quote the next similar job with waiting time built in instead of assumed away. WorkTickets' burden-rate configuration by work center (available on Professional and above) is what makes this roll-up possible without a separate spreadsheet reconstructing it after the fact. For the full mechanics of converting reason-coded minutes into a dollar figure, see downtime cost calculation for manufacturing.
OEE vs Job Costing: Two Different Lenses on the Same Floor
Overall Equipment Effectiveness (OEE) — the classic availability × performance × quality formula — asks a plant-level question: how effectively is this asset being used against its theoretical maximum? Job costing asks a job-level question: did this specific job consume more labor and machine time than it was quoted for, and why?
The two lenses use overlapping data — the same coded downtime events feed both — but they answer different questions for different audiences. A plant manager tracking OEE wants an asset utilization trend line. A job shop owner deciding whether to hold or raise the price on the next similar job wants an actual-vs-quoted comparison at the operation level, tied to the specific reason the hours ran over. WorkTickets is built around the second question: actual-vs-quoted labor per operation and per job, on every tier, so that the same downtime event that would feed an OEE denominator instead feeds a direct answer to "was this job priced right." The distinction is worth understanding before choosing which metric a shop actually reports on — our companion piece on OEE vs job costing works through it in more depth.
Ranking the Real Cost Drivers
The point of machine downtime analysis isn't a dashboard full of numbers — it's a ranked list. Once reason-coded events are rolled up by work center and converted to cost, sort them, largest first. The result is usually not what the room expected. Shops often assume their biggest loss is a slow machine; the rollup frequently shows it's a upstream waiting condition — late material, an approval bottleneck, an inspection queue — that's strangling a perfectly capable machine.
That ranked list is also how bottleneck identification stops being a matter of opinion. Instead of the loudest voice in the room naming the problem station, the data names it. For a structured method to walk from a rollup to a defensible bottleneck call, see job shop bottleneck identification.
A machine that looks busy and a machine that's actually producing good parts against its quoted hours are two different claims — and only one of them is provable without reason-coded data.
Building the Habit: From One-Off Analysis to Standing Practice
A single downtime analysis, run once as a special project, tends to fade. The shops that get lasting value out of this turn it into a standing weekly or monthly review: pull the rollup, check the ranked list, ask whether last month's top driver moved. Scrap and rework logged against the causing operation — a feature available on every WorkTickets tier — closes the loop further, connecting a downtime event not just to lost time but to a quality root cause worth fixing at the source.
For shops building this discipline from scratch, our broader guide to execution and costing for small job shops walks through where downtime analysis fits alongside routing, traveler generation, and actual-vs-quoted reporting as one connected system rather than a set of separate tools.
If your shop is ready to start coding and rolling up downtime data without building the tracking sheet from scratch, our Downtime & Reason-Code Analysis Workbook gives you the reason-code categories, the rollup structure, and a worked cost-conversion template to start the next review with real numbers instead of a blank spreadsheet.
