Downtime Tracking: How to Categorize Causes (Template)

First decision: planned vs unplanned

Before any reason codes, decide what counts against the machine at all. Planned exclusions — scheduled breaks, planned maintenance windows, no-demand time — come out of planned production time and don't count as downtime. Everything else that stops production is unplanned downtime and gets a reason code.

The critical part is that this boundary is written down once and never moved shift to shift. The most common way downtime data goes bad is quiet reclassification: a rough week, and suddenly a 40-minute breakdown becomes 'planned maintenance' because someone decided to true it up. Once the boundary flexes, every trend line after that is fiction.

Tip Changeovers are the boundary case everyone argues about. The common OEE convention counts them as unplanned availability loss — you knew the setup was coming, but the machine still wasn't producing. Whichever way you decide, write it into the definition and keep it fixed.

The starter reason-code list

A good taxonomy has three properties: an operator can pick the right code in five seconds, every code maps to a different owner or fix, and 'other' stays rare. Twelve codes in four groups covers most discrete-manufacturing floors:

• EQUIPMENT — Breakdown, mechanical: physical failure — bearings, belts, hydraulics, tooling breakage. Owner: maintenance.
• EQUIPMENT — Breakdown, electrical/controls: drives, sensors, PLC faults, alarms that need a reset-and-investigate. Owner: maintenance/controls.
• EQUIPMENT — Tooling: tool change outside planned schedule, tool not available, tool rework. Owner: tooling/production.
• CHANGEOVER — Setup: the core changeover, from last good part of job A to first good part of job B. Owner: production.
• CHANGEOVER — First-article/adjustment: dial-in and inspection wait after setup is nominally done. Owner: production/quality.
• SUPPLY — No material: raw stock or components not at the machine. Owner: scheduling/purchasing.
• SUPPLY — Wrong/bad material: material present but unusable — wrong spec, damaged, failed incoming check. Owner: purchasing/quality.
• SUPPLY — Blocked downstream / starved upstream: the machine could run but the flow around it can't. Owner: scheduling.
• PEOPLE — No operator: machine idle because the trained person is elsewhere — covering another machine, in a meeting, absent. Owner: supervision.
• PEOPLE — Waiting on decision/inspection: idle pending quality disposition, engineering answer, or supervisor call. Owner: whoever owes the answer.
• PROCESS — Quality stop: production halted to contain a defect run. Owner: quality/process engineering.
• OTHER — with a mandatory free-text note. If OTHER exceeds roughly 10% of downtime minutes in a month, mine the notes and promote the recurring cause to its own code.

Notice what's not here: no code for 'micro-stops'. Stops under a minute or two shouldn't be logged individually — nobody will do it, and the attempt destroys logging discipline for everything else. Micro-stops are captured in aggregate by the Performance factor of OEE (actual count versus ideal rate), which is the right instrument for them.

Logging rules that keep the data honest

1. Log at the machine, at the time of the stop — duration, code, one line of free text. Reconstructed-at-shift-end logs lose the short stops and round everything to the nearest 15 minutes.
2. One stop, one entry. A 50-minute stop that was 20 minutes waiting for maintenance and 30 minutes of repair is two entries if you ever want to attack response time separately from repair time.
3. The operator picks the code; the supervisor reviews weekly. Recoding entries after the fact without the operator kills trust and, soon after, participation.
4. Set a minimum log threshold and say it out loud — five minutes is common. Below that, the stop belongs to Performance, not the downtime log.
5. Review the Pareto every week with the crew: top three codes by total minutes, and what's being done about #1. Data that visibly drives action is data people keep entering.

The weekly Pareto is the whole payoff. Sorted by total minutes — not by count of events — it converts a month of entries into a ranked fix list: if 'CHANGEOVER — Setup' owns 240 minutes a week across three machines, that's your project, regardless of how dramatic Tuesday's breakdown felt.

Failure modes to design against

• Too many codes. Past roughly a dozen, operators stop reading the list and default to the first plausible option. Depth comes from the free-text note, not from code #31.
• Codes that name symptoms instead of owners. 'Machine stopped' is useless; every code should imply who acts on it.
• Blame-shaped codes. If 'operator error' is on the list, it will be underused by operators and overused by everyone else, and the real causes (training, procedure, fixturing) stay invisible. Log what happened, not whose fault it was.
• Letting OTHER become the biggest bucket. It's the canary: a swollen OTHER means the taxonomy no longer matches the floor.
• Tracking downtime but never closing the loop. If the top code hasn't changed in six months and nothing was launched against it, the crew is right to stop logging carefully.

Tip Run the taxonomy as a draft for the first two weeks and let operators propose changes. A code list the crew helped shape gets used; one laminated and handed down does not.

Common questions

Related guides