Manufacturing Downtime Tracking: How to Measure, Classify, and Reduce Stops

Every plant manager knows the machine stopped. Very few can say why, for how long, and, crucially, how often it happens in stops too short to notice. Downtime tracking is the discipline of turning "the line had a bad week" into "line 3 lost 6 hours to no-material waits and 4 hours to micro-stops on Tuesday."

This guide covers how to capture downtime automatically, how to classify it so the data stays honest, and how to read the Pareto that tells you where to fix first.

Automatic vs Manual Capture

There are two ways downtime gets recorded, and they produce very different data:

	Manual (clipboard / app)	Automatic (sensor / PLC)
Who records	Operator	Machine signal
Start/stop accuracy	± minutes (if remembered at all)	± seconds
Micro-stops	Invisible	Captured
Night shift	Depends on the operator	Always on
Reason code	Operator taps it	Needs a human or inference

The finding that surprises most plants: automatic capture routinely reveals 2–5× more downtime than manual logs. Not because operators lie, but because short stops and slow running never get written down. A machine that "ran fine all shift" on paper often lost 15% of its time to 30-second jams.

Classifying Machine States

Downtime tracking starts with a state model. Every machine is in exactly one state at any moment:

• Running: producing at the expected rate
• Planned stop: breaks, maintenance, scheduled downtime
• Changeover: switching product or tooling
• Breakdown: unplanned fault, waiting for repair
• Micro-stop: brief stoppage, under a minute
• Slow cycle: running below ideal speed
• Defect: producing but scrapping output

A single digital signal (the run lamp, the contactor, the PLC's running output) distinguishes Running from Stopped automatically. Distinguishing the types of stops (breakdown vs changeover vs planned) usually needs the reason-code tap, or a rule like "fault lamp on = breakdown."

Reason Codes: The Data Plant Managers Act On

Raw downtime tells you "the machine stopped." Reason codes tell you "stop happened because of X", and that is what drives improvement. The rules that keep reason codes useful:

• Five to eight codes per line. More than that and operators guess. "No material," "Setup," "Mechanical fault," "Waiting QC," "Break," "Other" covers most lines.
• Use the operators' language. If the floor says "waiting mold," the code says "waiting mold", not "tooling logistics delay."
• One tap when it stops, one tap when it restarts. The code attaches to the stop interval, and the duration is measured, not estimated.

The classic failure: reason codes are too generic ("Maintenance") to act on, or too detailed to be entered consistently. The Pareto below is only as good as the code vocabulary.

Reading the Downtime Pareto

After a few weeks of automatic capture, sort downtime by reason code. The Pareto principle holds almost every time: a handful of reasons account for most of the minutes.

Reason              Hours   % of total
────────────────────────────────────────
No material          14.5    31%
Mechanical fault      9.2    20%
Setup / changeover    6.8    15%
Waiting QC            4.1     9%
Micro-stops (Σ)       3.6     8%
Break                 3.2     7%
Other                 4.8    10%

Three reads from this chart:

1. No material dominates. That is a logistics problem, not a maintenance problem: a different fix, a different owner, and usually the fastest win.
2. Micro-stops add up. Never logged before, now 8% of all lost time. Small jams, sensors, and adjustments: the classic hidden performance loss.
3. Mechanical fault is significant but not #1. The instinct would have been to blame the machines; the data says material supply first.

From Tracking to Reduction

Downtime reduction is a loop, not a project:

1. Measure: automatic capture, reason codes, real durations.
2. Rank: weekly Pareto by line and shift.
3. Fix the top reason: one at a time. It is usually cross-functional (material, QC, changeover procedure) more often than it is a repair.
4. Verify: next week's Pareto shows whether the minutes actually moved. If they did not, the code vocabulary or the fix was wrong.

This is the same loop OEE runs on: Availability improves as downtime drops, Performance improves as micro-stops get fixed, and the OEE number moves as a consequence.

Downtime Tracking With Voltrus OEE

Voltrus OEE captures downtime the automatic way: a sensor node reads the machine's digital status signal, a tower lamp broadcasts the state across the floor, and every stop is timestamped and classified. Operators tap a reason code from a handheld or the mobile app; scrap is logged the same way. The dashboard ranks downtime by reason per line and per shift, the Pareto, live, without anyone compiling it.

Keep reading

Guide OEE Formula Explained: Availability × Performance × Quality With a Worked Example August 16, 2026 Guide How to Track OEE on the Factory Floor (Without an MES Project) August 16, 2026 Guide Manufacturing Downtime Tracking: How to Measure, Classify, and Reduce Stops August 16, 2026