How to track machine downtime and its causes

You capture every stop and its reason without slowing production by splitting the work. A machine signal records when each stop starts and ends, rules name the routine stops, and operators add a reason only to the stops a rule can't explain, in one tap at the machine. Nobody writes times down, so the record catches the two-minute stops a paper log misses.

This guide is for plant managers and maintenance leads setting up downtime tracking on a cell or a whole floor. It works one shift by hand, shows which stops a rule can name, and ends with a checklist for the first week.

What a downtime record holds#

The second half of that definition is the one plants get wrong. A stop with no reason is still downtime, as the downtime glossary entry puts it. A reason changes what you can say about stopped time, not how much of it there is.

Each stop becomes one record with a handful of fields. The trick is to ask each field from whoever already knows it.

The machine knows when it stopped and restarted, to the second. A rule knows that a 90-second pause is a short stop, or that a stop inside the lunch window is lunch. Only a person knows that the coolant pump tripped.

Why paper logs miss most stops#

Many plants estimate downtime rather than measure it. NIST's Machinery Maintenance Survey asked US discrete manufacturers what percent of planned production time is unplanned downtime, and NIST estimates the share at 7.8% across the sector.^[1] NIST adds that the survey asks about issues that, "for many firms, are not formally tracked."^[1]

A paper log fails in a predictable way. It records the stops someone had time to walk over and write down, and it rounds them. A two-minute jam cleared at the machine never reaches the log sheet.

Whether those 48 short-stop minutes count against availability or performance depends on your short-stop cutoff, as where micro-stops show up in OEE explains. Either way, a paper log can't put them anywhere, because it never saw them.

Where the missing minutes come from breaks a paper log's gap down by source: rounded times, the shift start and short stops.

Record the stop automatically#

Four methods can record when a machine stops. They differ in what they catch and in how much they ask of the operator.

You don't need a controller connection to track downtime. Start time, end time and a reason are the whole record, and a sensor on the outside of the machine supplies the times on any machine. The sensor and PLC comparison covers what each one sees.

Two settings decide how clean the record is:

• Separate a stop from a pause in the cycle. A machining center that pauses 20 seconds to change a tool between parts is running, not down. Set the stop threshold above the longest pause that belongs to the cycle, then check it against a stopwatch over 10 cycles.
• Keep missing data out of downtime. When a sensor loses power or its connection, record that time as unknown, not as stopped. Otherwise a sensor unplugged over a weekend reads as 48 hours of downtime. The metrics reference calls this unknown time.

Keep the reason list short#

The list decides whether the data is worth reading. An operator facing 40 codes on a touchscreen in the middle of a shift picks the first plausible one. The chart then ranks the order of your list, not the losses on your floor.

Four rules keep a list usable:

• 8 to 12 codes that operators pick, each named for something a person can fix. Machine problem names nothing and wins every month.
• A planned flag on every code, set when you build the list, so changeovers and preventive maintenance read apart from failures.
• A required note only where the code alone says nothing actionable, such as Breakdown and Other.
• An owner for every code, the person who acts when that code tops the chart.

Split the list by who assigns each code. Rules assign Short stop, Start of shift, End of shift and Lunch break. Operators pick the rest, such as Changeover, Waiting for material, Tool problem and Breakdown.

A full starter list with severities is in which reason codes to log.

Keep No job scheduled apart from the failure codes. A machine with no work is idle rather than down, and the fix lives in the schedule, not on the floor.

Get a reason without slowing the line#

The goal is fewer questions, not faster answers. In the example shift, 24 of the 27 stops were short stops. A rule that labels every stop under a 5-minute cutoff leaves the operator three stops to explain in 8 hours.

Those three stops hold 74 of the 122 stopped minutes, 60.7%. The operator spends attention where the time is, and the rule handles the rest with no one touching it.

1. Classify short stops by rule

   Set a cutoff below the shortest stop you want a person to explain, such as 5 minutes. Every stop under it gets Short stop from one of the automatic classification rules.

2. Classify shift edges and breaks by schedule

   Stops at the start and end of a shift, and inside a lunch window, take their reason from the shift calendar. Turn these rules on only after the shifts in your system match the floor, or real downtime gets filed under Lunch break.

3. Ask at the machine while the stop is open

   Put the reason picker at the machine, on a tablet or the machine's own screen. A reason chosen during the stop beats one reconstructed at the end of the shift.

4. Classify a run of stops at once

   When five stops share one cause, such as a mold wash, select them together and classify them in bulk. Never clear a backlog by labeling it all Other.

5. Split a stop that holds two causes

   A 90-minute stop where a changeover ran into a breakdown at minute 30 is two records: 30 minutes of Changeover and 60 minutes of Breakdown.

6. Alert on stops that run long

   Set a warning above your normal changeover and a critical time well past it, for example 15 and 45 minutes. Someone then walks to the machine while the cause is still in front of them. Machine Down alerts take both thresholds.

You probably don't need an end-of-shift review form. When the picker sits at the machine and rules cover the routine stops, the supervisor's job shrinks to the handful of stops still open at shift change.

Check the record every day#

A downtime record can look complete and still be wrong. Three numbers tell you whether to trust it, and each takes a minute to read at the start of the day.

For example, on a 450-minute shift with 122 stopped minutes, 5% is about 6 minutes. If the morning report shows 30 unclassified minutes on one machining center, ask that shift's operator today, while they still remember. Read the notes under Other once a week: a cause that repeats there is the next code to add.

Review the stops every week#

A downtime Pareto ranks reasons by the minutes they cost, longest first, with a running total. It shows how few reasons make up most of the loss.

Rank by minutes, not by count. In the example shift, Short stop is 24 of 27 stops, 88.9%, so a chart by count shows little else.

Ranked by minutes, Short stop holds 48 of 122, 39.3%, and the 38-minute changeover sits close behind it. One changeover costs nearly as much as two dozen jams, and only the chart by minutes shows it.

Review the chart at a fixed weekly slot, with production, maintenance and the shift leads in the room. Take the top three reasons, give each an owner and a date, and check last week's three against this week's chart.

Building a downtime Pareto works a full week through. The IoTFlows docs show how to read the Pareto and trend charts.

Datwyler's injection molding plant in Ontario, California, runs this pattern on more than 20 machines. Automatic rules classify short downtimes and stops at the start and end of each shift, and operators and supervisors classify the rest.

Week over week, the reports showed that Tuesday shift transitions added 8 to 10 minutes of downtime every week. Within six months the plant cut shift-changeover downtime 50% and material-changeover downtime 30%, as Datwyler's story describes.

Track downtime automatically#

A SenseAi sensor mounts magnetically on the outside of each machine and reads its vibration and sound, with no PLC connection. It decides running or stopped every second, so every stop is on the machine's timeline within seconds and no one writes anything down.

Operators put a reason on a stop in a tap, at the machine, in Operator View or in the iOS app. Reason codes sit under severity headings, with required notes and planned flags. Four automatic rules classify short downtimes, shift starts and ends, and a machine down for a whole shift, and break windows cover lunch and breaks.

The Downtimes report ranks reasons by the hours they cost, with trends by interval and by machine. A classified stop can open a Maintain work order from the same dialog. See how the pieces fit on downtime tracking.

Start tracking downtime this week#

1. Enter your shifts and time zone before you read any number, because shift-edge and break rules depend on them.
2. Pick one cell to start, ideally the one that limits output.
3. Record start and end times from a machine signal, and check one shift against a stopwatch.
4. Load 8 to 12 operator reason codes, each with a planned flag and an owner.
5. Turn on the short-stop rule on day one, and the shift-edge rules once the shifts match the floor.
6. Set long-stop alerts above your normal changeover time.
7. Read the three daily checks each morning.
8. After one week, read the Pareto and give the top three reasons an owner and a date.

You don't need OEE to start. Stopped minutes by reason are the input to availability, so a clean stop log makes calculating OEE arithmetic later.