Track Production Downtime with a Clear Event Log

Define downtime before measuring it

Agree on the production boundary: planned production time, scheduled breaks, changeovers, cleaning, planned maintenance, no-demand periods, and the threshold that distinguishes a stop from a slow cycle. Keep these categories separate so Availability, utilization, and calendar loss are not mixed.

Use one event model across assets: start time, end time, asset, detected state, production order, product, shift, duration, initial reason, confirmed cause, responder, and effect. Never force operators to choose a root cause while the line is still down.

• Detected state: what the control system observed
• Reason: the best current operational classification
• Confirmed cause: evidence after investigation
• Impact: lost good output, constraint time, service, quality, or safety exposure

Capture events at the right resolution

Controller states and counters can capture short events that manual logs miss, but automated data still needs context. Debounce chattering signals, reconcile overlapping states, handle communications gaps, and preserve raw events. A one-minute threshold may simplify reporting while hiding hundreds of repeated 20-second jams.

Allow operators to add context with a short, controlled workflow. Use a small reason hierarchy, an “unknown, investigate” option, and notes only when they add evidence. Measure code completeness and later corrections; do not reward a high coding rate if people are guessing.

One event record, with the unknowns left visible

Use half-open intervals: include the start, exclude the restart. A stop from 08:00:00 to 08:00:20 lasts 20 seconds. Adjacent records can then share a boundary without counting that instant twice. Use a timezone or UTC timestamp, a unique event ID and the same asset boundary.

A stopped machine can be failed, starved or blocked. The detected state describes what the equipment did; the operator’s reason is an observation. A confirmed cause needs investigation. Keep “unknown” available and retain corrections with their author and time.

The fictional log below covers one machine over ten planned production minutes. Its three non-overlapping stops total 180 seconds. Alarm A17 supports a jam observation for the third stop, but it does not prove why the jam occurred. A communications gap remains missing data rather than becoming a stop or productive time.

Change the threshold, keep the loss

Vorne’s Six Big Losses guidance permits a documented threshold between availability stops and small stops counted in performance. In this example, a stop at or above the threshold is an availability loss. Shorter stops remain inside run time and reduce performance.

At a 60-second threshold, availability loses 120 seconds and performance includes the other 60 seconds. At 30 seconds, those amounts become 160 and 20 seconds. The raw interruptions still total 180 seconds. Never subtract a short stop from run time and charge it to performance a second time.

Hold planned time at 600 seconds, ideal cycle at 3 seconds and total/good count at 140 units. Fully productive time is 420 seconds, so OEE is 70% under either rule. The threshold changes the split, not the physical result. Keep the raw records if you need to compare reports later.

Separate where the loss appeared from where it started

In connected lines, a station may be idle because it is failed, starved, blocked, waiting for quality release, or following a schedule rule. Align upstream and downstream state changes, buffer levels, counts, and order transitions to reconstruct the sequence.

Report equipment downtime and system-output impact as different measures. A long stop on a non-constraint with buffer protection can lose no shipments, while repeated microstops on the constraint can remove saleable output immediately.

Turn a Pareto chart into an investigation queue

A Pareto is a starting point. Slice by asset, product, shift, operating state, duration band, recurrence, and constraint status. Combine total duration, event count, mean time to respond, mean time to repair, and lost output. A broad “mechanical” category is not actionable.

Select a recurring, consequential pattern and build a synchronized timeline. Compare affected and unaffected runs, review alarms and process conditions, observe the work, and test causal candidates. Keep containment, cause, corrective action, and verification as separate fields.

1. Detect

   Capture the state change and preserve raw evidence.

2. Classify

   Record a useful reason without pretending it is proven.

3. Contextualize

   Add order, product, asset state, buffer, and constraint context.

4. Investigate

   Test recurring high-impact patterns for mechanism and cause.

5. Verify

   Confirm recurrence and system impact after the intervention.

Use prediction only after the tracking foundation works

Predictive maintenance needs confirmed fault labels, reliable sensor history, and a clear intervention window. If stop codes are inconsistent and repair outcomes are missing, an advanced model learns administrative noise.

Start with tracking and response discipline, then add anomaly detection or failure prediction where signals provide useful lead time. Evaluate false alarms, missed failures, response feasibility, and production impact together.

Use the log for the next question

Rank comparable reasons with downtime Pareto analysis. Investigate a recurring pattern with root-cause analysis. For MTBF and MTTR, first select confirmed failures and the correct operating/repair clocks; not every stop is a failure. Use the OEE formula to reconcile time and counts.