The Reason Code That Never Gets Picked
A machine sits idle for forty minutes. The operator glances at the tablet, sees a dropdown with fourteen downtime categories — Tooling Change, Material Shortage, Fixture Rework, Programming Delay, Operator Break, Quality Hold, Waiting on Prior Op, Maintenance Called, and half a dozen more — and picks whichever one is closest to the top of the list, or the one from muscle memory, or nothing at all. By Friday, the downtime report says 60% of the week's stoppages fall under "Other." Nobody can act on "Other."
This is the most common failure mode in shop-floor data collection, and it isn't a training problem — it's a design problem. Shops that build an elaborate downtime taxonomy on paper, hoping it will produce granular insight, usually get the opposite: operators under time pressure default to guessing, and the resulting data is too noisy to support any real decision about where capacity is actually being lost.
The fix is not more categories. It's fewer, better ones — a set small enough that an operator can classify a stoppage correctly in under two seconds, every time, without opening a manual. This article lays out that set, why four codes is close to the practical ceiling, and how to turn the resulting log into something that actually changes a quote or a shift schedule.
Why a Small Code Set Beats a Detailed One
The instinct to build a long list of downtime reasons comes from a reasonable place: more detail should mean more insight. In practice, code-set size and data quality move in opposite directions once a shop crosses roughly four to six options at the point of entry.
Three things break down as the list grows:
- Selection time increases. An operator standing at a machine that just stopped is not going to scroll through a long dropdown before tagging the reason — they'll tap the fastest match, correct or not.
- Category overlap creates ambiguity. Is a mis-loaded fixture "Tooling," "Fixture," or "Operator Error"? With enough categories, most real-world stoppages plausibly fit two or three of them, and the choice becomes arbitrary.
- Analysis effort increases faster than insight. A downtime log with twenty codes still has to be rolled up into three or four buckets before anyone can act on it — so the extra granularity gets thrown away at the reporting stage anyway.
The practical target is a set small enough to memorize and mutually exclusive enough that any stoppage has exactly one obvious home. Four codes — setup, run, waiting, rework — meet both bars for the large majority of small job shops in CNC machining, sheet metal fabrication, welding, plastics fabrication, and light assembly.
The Four Codes: Setup, Run, Waiting, Rework
Setup
Time spent preparing a work center to run a specific operation — loading a program, dialing in a fixture, staging tooling, first-piece approval before production cuts begin. Setup is expected time; the question worth asking isn't "did setup happen" but "how did actual setup compare to what the routing assumed." That comparison is the foundation of setup vs. run time tracking, and it's usually the single biggest lever in a quote that's drifting from actual cost.
Run
Time the operation is actually cutting, welding, forming, or assembling. This is the number a routing's standard time is trying to predict. Run time logged against an operation, compared to the routing's standard, is the core of per-operation job costing — it's the only downtime code that isn't downtime at all, but its accurate capture is what makes the other three meaningful by contrast.
Waiting
Time the operator or machine is idle for a reason outside the operation itself — waiting on a prior operation to finish, waiting on material, waiting on an inspector, waiting on a fixture that's in use elsewhere. Waiting is the code that most directly exposes scheduling and flow problems rather than machine or operator problems, and it's usually the fastest-growing category once a shop starts actually measuring it.
Rework
Time spent correcting a part that didn't pass inspection or didn't meet print the first time — re-cutting a feature, re-forming a bent panel, re-running a weld pass. Rework logged against the specific operation that caused the defect (not just "rework, general") is what makes a scrap or quality problem traceable back to a cause instead of a vague sense that "quality's been off lately."
Four categories, no overlap, and each one answers a different operational question: is my quoted time realistic (setup, run), is my flow broken (waiting), or is my process producing defects (rework). That's the whole diagnostic frame a small shop needs before adding a single additional code.
The value of a reason code isn't how precisely it describes the stoppage — it's whether operators will tag it correctly under time pressure, every time, for months.
When a Fifth Code Is Actually Warranted
Four codes cover the overwhelming majority of small shops, but there are legitimate cases for a fifth — typically a single added code for a shop with one dominant, recurring, high-cost stoppage category that setup/run/waiting/rework genuinely can't distinguish. A shop running a lot of outside processing (plating, heat treat) might add a "waiting — outside process" sub-tag. An aerospace-adjacent shop doing heavy first-article inspection work might separate "waiting — FAI hold" from general waiting, since first-article delays are a distinct, trackable cost driver tied to AS9102 documentation rather than ordinary flow congestion.
The test before adding a fifth code: will this category change a decision the four base codes can't already support? If the answer is "it would be nice to know," it's not worth the selection-speed cost. If the answer is "we're currently blind to a specific, recurring, expensive stoppage," it's worth the trade.
Turning Tagged Downtime Into Machine Downtime Analysis
A reason code is only as useful as the report built on top of it. Once setup, run, waiting, and rework are being tagged consistently at the work-center level, the natural next step is machine downtime analysis — rolling logged time up by work center, by shift, by job, and watching for the pattern that a single day's log can't show: the same work center losing an unusual share of its week to waiting, or the same operation across multiple jobs consistently running rework at a rate the routing never accounted for.
This is also where downtime cost calculation becomes possible rather than theoretical. Once time is tagged to a code and an operation, it can be priced at that work center's burden rate — turning "the saw was down for three hours Tuesday" into a dollar figure tied to a specific cause, rather than a vague sense that Tuesday was slow.
Rework carries a cost worth taking seriously on its own. Scrap and rework together cost the average manufacturer up to 2.2% of annual revenue, according to EASE.io — a number that only becomes actionable once rework time is logged against the operation that caused it, rather than absorbed into general downtime nobody traces back to a source.
Why Paper and Memory Undercount All of This
Shops running paper travelers or end-of-shift recall instead of real-time tagging aren't just missing detail — they're missing accuracy. Timeero reports that paper-based time tracking carries a calculation error rate as high as 8% of total payroll, and that error compounds when the underlying entries are reconstructed from memory hours after the stoppage happened rather than tagged at the moment it occurred. A downtime log built from end-of-day guesswork isn't a weaker version of a real-time log — it's a different, less trustworthy dataset.
This is the specific gap a lightweight execution layer is built to close, without pulling a small shop into a full ERP deployment it didn't budget for. WorkTickets ships with exactly this four-code downtime taxonomy — setup, run, waiting, rework — captured at one-tap clock-in/out on a kiosk or mobile device, tied to the specific operation on the job's routing, at every tier including Essentials. It's part of a deliberately narrow positioning: WorkTickets is a standalone, SaaS-native execution-and-costing layer that sits below full ERP, priced for a shop that has already decided a JobBOSS2- or ProShop-scale deployment isn't the next move.
Rolling This Out Without a Training Cycle
The rollout for a four-code set doesn't need a meeting. It needs the codes posted at the work center, the same four buttons on every device, and one supervisor spot-checking entries for the first week to catch operators defaulting to the same code out of habit. Because the set is small and mutually exclusive, most shops see consistent tagging within days rather than the weeks a longer taxonomy typically takes to bed in.
For a shop mapping this against its full costing model — burden rates, actual-vs-quoted comparisons, and where reason codes fit into the bigger picture — the small job shop execution and costing guide walks through the whole chain from routing to traveler to logged actuals.
To put this four-code structure to work immediately, the Downtime & Reason-Code Analysis Workbook provides a ready-to-use tagging reference and a rollup template for turning a week of setup/run/waiting/rework entries into a work-center-level downtime report — no software commitment required to start using it.
