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

By Dzulfikar Ats Tsauri, founder of Voltrus / JoyoDigitama. He builds the protocol tools covered in these posts. Updated October 28, 2026.

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 get machine state from signals the PLC already has, how to classify stops 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."

Getting State From Signals the PLC Already Has

You rarely need to change PLC logic. Walk up to the machine and look at its HMI: it already shows running, stopped, faulted or manual, and that comes from bits and registers you can read. Four signals cover most machines:

• Run signal: a boolean that is true while the machine is producing (often called Auto Run, Machine Running or Production Active).
• Fault signal: the same bit the HMI uses to show an alarm.
• Count or speed: a part counter that increments, or a line speed value. If the counter is rising, the machine is producing.
• Mode selector: Auto, Manual, Setup or Maintenance.

The classification is a handful of rules, applied by whatever reads those signals, not by the PLC:

• Run true and count rising (or speed above a threshold): Running
• Run false and fault true: Breakdown
• Run false and mode is Setup: Changeover
• Run false, no fault, mode is Manual: Manual or idle
• Run false and none of the above: Idle, which needs an operator reason

Use the counter as a cross-check on the run signal. A run lamp that stays on while the counter stops moving is a jam or a starved machine, and that is exactly the slow-cycle and micro-stop loss a bare run signal hides.

Log every state change with a timestamp. Running to Breakdown at 10:32:15 and back to Running at 10:47:03 is 14 minutes 48 seconds of breakdown, measured, not remembered. Sum the intervals over a shift and you have Availability without touching the PLC program.

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.

In practice the flow is: the state changes to a non-running state, the operator is prompted for a reason, picks one from the list, and the stop interval is stored with the machine, the start time, the reason and a duration that is closed when the machine runs again. Define the list per line with the plant manager, because a packaging line and a machining cell fail in different ways. Then watch "Other". If it climbs past roughly a tenth of lost minutes, the vocabulary is missing a reason that people keep running into.

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 Line

Voltrus OEE Line records every machine state (running, idle, down) with a timestamp, and each stop carries a reason code marked planned or unplanned. Operators tap the state and reason on a phone-friendly screen opened from a link, with no login, and count good and scrap pieces the same way. If a PLC, the Voltrus Gateway or a script already knows the machine state, for example by applying the signal rules above, it can push states and counts over HTTP instead. The downtime view ranks reasons per machine and per shift, and an email alert goes out when a machine has been down longer than a number of minutes you set.

Keep reading

Guide OEE Formula Explained with a Worked Example August 16, 2026 Guide Manufacturing Downtime Tracking: Measure, Classify, Reduce Stops August 16, 2026