---
title: "Which downtime reason codes to log, and how many"
description: "Log 8 to 12 reasons operators pick by hand, plus a few that rules assign to routine stops. Get a 15-code starter list, rules for each code and a worked Pareto."
category: "Downtime and utilization"
author: "Data Analytics Team"
published: "2024-04-22"
updated: "2026-10-20"
source_url: "https://www.iotflows.com/blog/downtime-reason-codes/"
---
> Question: Which downtime reasons should we log, and how many is too many?

## Key takeaways

- Keep the list operators pick from to 8 to 12 reason codes, so the right one is visible without scrolling.
- Let rules classify routine stops such as short pauses, shift starts and ends, breaks and shifts with no job.
- Name each code after what the operator saw and the fix it leads to, not after a suspected root cause.
- Set severity and the planned flag separately, because a scheduled four-hour rebuild is planned and still costly.
- Rank stopped hours by reason every month, and give each of the top three reasons an owner and a date.

Log a reason for every stop someone would act on, and keep the list operators pick from to 8 to 12 reasons. Add four or five reasons that rules assign to routine stops, such as short pauses and shift starts, and the whole list stays under 20. A list is too long when operators scroll to find a reason, or when its biggest Pareto bar names no fix.

This guide is for plant managers and the operators who classify stops. It gives a 15-code starter list, the rules for writing each code, and one month of stops ranked by reason, worked by hand.

## What a downtime reason code is

> **Definition.** **Downtime reason code** is a short label that says why a machine stopped, such as Changeover or Waiting for material, picked from a fixed list so that every stop with the same cause is counted under the same name.

The fixed list is the point. A free-text box collects “down”, “dwn” and “machine down” for the same stop, and none of them can be added up. A code can: 40 stops coded `Waiting for material` sum to an hour total you can rank.

The IoTFlows docs call a reason code a *downtime category*, defined in the [glossary](/docs/get-started/glossary/#downtime-category).

Three settings on each code make it more than a name:

| Setting | Question it answers | Example |
|---|---|---|
| Severity | How much does this stop cost? | Breakdown is High; Lunch break is None |
| Planned | Did we schedule this stop? | Preventive maintenance is planned |
| Required note | Is the code enough to act on? | Breakdown needs a note; Changeover doesn’t |

[Severity](/docs/get-started/glossary/#severity) and planned are separate questions. A four-hour rebuild you scheduled is planned and still High, because it takes four hours of capacity whether or not you chose it.

## How many reason codes is too many?

Keep the codes operators pick by hand to 8 to 12. Operators classify mid-shift, often on a touchscreen at the machine. When the list scrolls, the first plausible code wins, and the ranking then measures the order of the list rather than the plant.

A longer list doesn’t buy more detail. With 40 codes, one cause ends up split across `Material late`, `No material` and `Waiting for forklift`, and each of the three looks too small to fix. Merged, they make one bar that tops the chart.

Your list is too long when:

- Operators scroll or search to find a code.
- Two codes lead to the same fix, as staging material fixes both `No material` and `Waiting for forklift`.
- A code has collected no stops in three months.

Your list is too short when:

- The tallest bar names no action. `Machine problem` wins every month and tells you nothing to fix.
- `Other` ranks among your top three reasons.

Add a code only when someone would act differently because of it. Remove or merge one each time you add one, so the operator list stays at 12 or fewer.

> **Split a code or keep it whole?**
>
> Split a code when its stops have different owners or different fixes. `Breakdown` and `Jam or misfeed` stay apart because maintenance fixes one and the operator clears the other. Keep a code whole when one person would make the same fix for every stop under it.

## A starter list of 15 reason codes

Start from this list and rename codes to your plant’s words. It has 5 codes that rules assign and 10 that operators pick, under four severity levels: None for stops that are nobody’s loss, Low for routine planned work, Medium for avoidable waits and High for stops that need someone now.

### Codes a rule assigns

| Code | Severity | Planned | Rule that assigns it |
|---|---|---|---|
| Lunch break | None | Yes | Stop inside a break window |
| No job scheduled | None | Yes | Machine down for a whole shift |
| Start of shift | Low | Yes | Stop running into a shift start |
| End of shift | Low | Yes | Stop running into a shift end |
| Short downtime | Low | No | Stop shorter than the cutoff |

### Codes an operator picks

| Code | Severity | Planned | Note required | Six big losses |
|---|---|---|---|---|
| Changeover | Low | Yes | No | Setup and adjustments |
| Preventive maintenance | Low | Yes | No | Setup and adjustments |
| Tool change | Low | Yes | No | Setup and adjustments |
| Waiting for material | Medium | No | No | Equipment failure |
| Waiting for operator | Medium | No | No | Equipment failure |
| Waiting for inspection | Medium | No | No | Equipment failure |
| Quality adjustment | Medium | No | Yes | Setup and adjustments |
| Jam or misfeed | Medium | No | No | Equipment failure |
| Breakdown | High | No | Yes | Equipment failure |
| Other | Medium | No | Yes | Any |

The last column maps each code to the six big losses as Vorne groups them. Vorne puts major adjustments under setup and adjustments. Any other unplanned stop that needs a reason counts as equipment failure, and stops under the cutoff are minor stops.

The [six big losses](/blog/what-is-oee/#six-losses) are the classic grouping of OEE losses. Vorne treats equipment failure as any unplanned stop, including a lack of operators or materials, and setup and adjustments as any planned stop, including cleaning, warm-up and quality inspections.[1] Mapping your codes to them once lets you read the Pareto and OEE in the same terms.

The names hold across machine types, so one list serves the whole plant. `Changeover` is a die change on a 350-ton press, a mold change on an injection molding machine and a fixture swap on a Haas VF-2. `Jam or misfeed` is a coil misfeed on the press and a fallen bottle on a filler. Put the machine-specific detail in the note.

## Which stops should a rule classify?

A rule should classify every stop whose cause you already know from the clock: short pauses, shift edges, breaks and shifts with no job. These stops make up most of the rows, and nobody needs to explain them. Leaving them to operators fills the queue with stops nobody wants to explain, and the stops that matter get skipped.

Figure: An 8-hour shift with eight stops. Rules classify six, 69 min: start of shift, three short downtimes, lunch and end of shift. The operator picks reasons for two, 65 min: a 40-min changeover and a 25-min wait for material.

*Rules take six of the shift’s eight stops; the operator explains the two that need a person. Sample data.*

In that shift the machine stopped eight times for 134 minutes. Rules classified six stops, 69 minutes. The operator classified two, 65 minutes, and those two are the ones a person can explain.

### Set the short-stop cutoff

Vorne describes minor stops as usually well under five minutes, and gives a policy of requiring a reason for any downtime longer than two minutes as an example.[1] The cutoff is a choice, not a standard. IoTFlows sets it per machine, at 5 minutes by default (see [short downtimes](/docs/monitoring/auto-downtime-rules/#short-downtimes)).

Set the cutoff just above the machine’s normal pause. For example, on a mill where loading a part takes 90 seconds, a 2-minute cutoff keeps every load out of the operator’s queue, and a 4-minute stop still asks for a reason.

Short stops below the cutoff still count as downtime. They collect under one code, so watch that code’s total. For where those stops land in OEE, see [micro-stops](/blog/micro-stops/#cutoff).

### Turn the rules on in order

1. Short downtimes first. They remove the most rows and hide the least.
2. Start and end of shift next, once your shift times match the floor.
3. Break windows, one per lunch wave.
4. Whole-shift stops last, only after you trust the shift calendar. A holiday the calendar calls a working shift reads as a full shift of downtime, and the rule files it under `No job scheduled`.

## Write codes that point at a fix

A code is only as good as the decision it leads to. These rules keep each one actionable.

- **Name what the operator saw.** `Waiting for material` is a fact at the machine. `Poor scheduling` is a conclusion, and it belongs in the review.
- **Require a note where the code alone can’t be acted on.** `Breakdown`, `Quality adjustment` and `Other` earn one. `Changeover` doesn’t: 40 notes that say “changeover” add nothing.
- **Set the planned flag when you build the list.** Going back later means rereading weeks of stops.
- **Split a stop that holds two reasons.** A 90-minute stop where a changeover ran into a breakdown at the 30-minute mark is 30 minutes of `Changeover` and 60 of `Breakdown`, see [split a downtime](/docs/monitoring/classify-downtime/#split).
- **Rename a code rather than delete it.** Deleting a code can unclassify every past stop that used it, and the history loses its reasons.
- **Classify at the machine, during the shift.** A [tablet assigned to each machine](/docs/monitoring/operator-stations/) puts the list where the stop happens, while the reason is fresh.

## How do you read the reasons once they’re logged?

You rank them. A Pareto chart sorts contributors from largest to smallest and adds a running cumulative percentage, which shows where the few reasons that carry most of the loss end. Joseph Juran called them the “vital few”.[2]

For downtime, rank by hours, not by the number of stops: 30 short pauses cost less than one 4-hour breakdown. The full method, from stop log to chart, is in [how to build a downtime Pareto](/blog/downtime-pareto/).

#### Worked example: One month on six CNC machines

- Six machines, two 8-hour shifts, 22 working days: 6 × 16 × 22 = 2,112 scheduled hours.
- Stopped time, with Lunch break filtered out because nobody acts on it: 240 hours, so 240 ÷ 2,112 = 11.4% of scheduled time.
- Top three reasons: Changeover 62 h, Waiting for material 48 h, Breakdown 30 h, for 140 h.
- Unclassified: 12 h, so 12 ÷ 240 = 5.0% of stopped time.

**Result:** Top three share = 140 ÷ 240 = 58.3% of stopped time

Figure: A Pareto of 240 stopped hours in one month. Changeover 62 h, Waiting for material 48 h and Breakdown 30 h reach 58.3% cumulative. Seven smaller reasons follow, from No job scheduled at 26 h to End of shift at 5 h.

*Three reasons carry 58.3% of the month’s stopped hours; the other seven share the rest. Sample data.*

Read it from the top, and match each bar to its fix:

| Leading bar | First move | Owner |
|---|---|---|
| Changeover, planned | Move setup work outside the stop | Process engineer |
| Waiting for material | Stage the next job before this one ends | Materials lead |
| Breakdown | Read the notes, open the repairs | Maintenance |
| Unclassified or Other | Fix the list or the habit first | Shift supervisor |

Sample data. Check Unclassified and Other before the rest: when either ranks in the top three, the chart is ranking missing reasons.

The leading bar is planned, and that matters. Planned doesn’t mean free: 62 changeover hours are 2.9% of the month’s scheduled time, and the fix is to shorten them, not to stop logging them. Give each of the top three bars an owner and a date, then compare next month’s chart to this one. The [rollout plan’s downtime phase](/docs/get-started/roll-out-plan/#phase-3) uses the same gate.

For the rest of the loss picture, the same reasons feed availability, see [how to calculate OEE](/blog/how-to-calculate-oee/#availability).

## Track reason codes automatically

A SenseAi sensor on each machine detects every stop in seconds, with no PLC connection or operator input. Operators put a reason on it in a tap, at the machine, in Operator View or in the iOS app, from categories under severity headings with required notes and planned-downtime flags.

Four automatic rules classify short downtimes, the start and end of a shift, and a machine down for an entire shift. Break windows add a reason for lunch and breaks. The [Downtimes report](/docs/monitoring/downtimes/#pareto) ranks reasons by the hours they cost, and a classified stop can open a Maintain work order from the same dialog.

Datwyler’s injection molding plant runs three of those rules, for short downtimes and the start and end of each shift, and its operators and supervisors classify the rest. Within six months it cut shift-changeover downtime by 50%, see [Datwyler’s story](/customers/datwyler/). See how it works on [downtime tracking](/solutions/downtime-tracking/).

## Prune the list every month

A reason list drifts. New codes get added for one-off stops, and old ones stop being used. Fifteen minutes a month keeps it honest.

1. **Read the Other notes.** Group last month’s `Other` notes by cause. When one cause shows up in several notes, give it its own code.
2. **Merge codes that share a fix.** Fold two codes into one when the same person would make the same fix for both, for example `No material` into `Waiting for material`.
3. **Retire unused codes.** Rename a code that has collected no stops in three months into one still in use, rather than deleting it, so history keeps its reasons.
4. **Check the unclassified share.** Compare unclassified hours with last month’s. A rising share means the classifying habit is slipping, not that the plant runs better.
5. **Recount the operator list.** Count the codes operators pick by hand. If the count is above 12, merge before the next month starts.

To set up the list in IoTFlows, see [design a category list](/docs/monitoring/downtime-categories/#design). For what the rest of the stop record should hold, see [what manufacturing data to collect](/blog/manufacturing-data-collection/).

## Questions

### Should micro-stops get their own reason codes?

Not one code each. Stops shorter than your cutoff, often two to five minutes, go under one automatic code such as Short downtime. Watch that code’s total hours machine by machine. When it grows on one machine, study that machine’s short stops on the floor, then add a specific code only for the cause you find.

### Who should classify a stop, the operator or the supervisor?

The operator at the machine, during the shift, because the operator knows whether the machine waited for material or for a program. The supervisor reviews unclassified stops at the end of each shift and corrects codes that look wrong. A reason added days later from memory is a guess, and it tilts the ranking toward whatever people remember.

### Is a changeover planned or unplanned downtime?

A changeover written into the schedule is planned. One nobody scheduled for that shift, such as a rush job swapped in mid-run, is unplanned. Planned does not mean free: a changeover still takes running time away, and changeovers are usually the largest part of setup time, which makes them a good target for setup reduction.

### What should we do with the Other code?

Keep it, require a note on it, and read those notes every month. When the same cause shows up in several notes, give it its own code and merge or retire one nobody uses, so the list stays the same length. If Other ranks among your top three reasons, the list is missing a code.

### Can every machine in the plant share one reason code list?

Yes, and one shared list puts every machine on the same Pareto. Choose names that hold on every machine type: Changeover covers a die change on a press, a mold change on a molding machine and a fixture swap on a mill. Keep machine-specific detail in the note, so no operator faces more than about a dozen codes.

## Sources

1. [Six Big Losses](https://www.oee.com/oee-six-big-losses/), Vorne Industries (OEE.com), accessed Oct 16, 2026
2. [Pareto Principle (80/20 Rule) & Pareto Analysis Guide](https://www.juran.com/blog/a-guide-to-the-pareto-principle-80-20-rule-pareto-analysis/), Juran Institute, accessed Oct 16, 2026