Downtime Reason Catalog

A downtime reason catalog is a standardized set of downtime codes used to consistently capture and analyze production stoppages. It is the prerequisite for OEE to be more than a number – it enables concrete action.

Without a catalog, you get free text – and free text produces data that cannot be compared or analyzed. No Pareto, no levers, no improvement.

Structure: How to Build a Downtime Reason Catalog

Three hierarchy levels are sufficient in practice.

Level 1 – Category answers: why is the line stopped in general? Robust main categories for a minimal start are technical fault, material and logistics, changeover and setup, quality and rework, organization and personnel, and planning.

Level 2 – Subgroup organizes within the category: under technical, for example sensors, drives, or grippers. Under material: infeed, missing parts, or quality issue.

Level 3 – Specific reason describes the event precisely: "light barrier contaminated," "material missing at workstation," "changeover extended."

Every reason needs a one-sentence definition that leads two different shifts to the same selection. Example: "material missing" means the line is stopped because material is not available at the workstation, even though the order has been released.

Why Start with 20–40 Reasons, Not 200

Too many reasons create selection stress and inflate the "other" category. The goal is not completeness but usability. Expansion comes only once data quality is stable. A catalog with 40 clean, defined reasons delivers better analytics than one with 200 undefined options.

Planned vs. Unplanned: The Distinction That Makes OEE Comparable

For reliable OEE figures, it must be defined what falls within planned production time and what does not. A common trap: breaks, planned maintenance, and planned product changeovers are treated inconsistently – leading to debates about numbers rather than causes.

Data Quality: System Logic, Not Appeals

Data quality does not come from training people – it comes from system logic. Mandatory reason selection above a defined downtime threshold – typically 2 to 5 minutes – prevents unclassified stoppages. Real-time entry at the event rather than at shift end improves accuracy. "Other" only with a mandatory comment and regular review so it gets converted into real reasons. And a top-10 list of the most frequent reasons per line reduces misclicks because operators see the most relevant options first.

Pareto Analysis: Three Views That Enable Action

Reading Pareto correctly means sorting by lost minutes, not by frequency. Frequency is secondary.

Three views provide different insights. Minutes show impact: what costs the most production time? Frequency shows stability: what happens constantly and disrupts flow? Average duration shows character: long events are typically technical or material issues; short ones are often process or operator related.

The drill-down that enables action runs from category through subgroup and specific reason down to the affected machine, shift, and product. Teams that cannot drill down to individual events stay in discussion mode rather than improvement mode.

What the Pareto Tells You About Actions

When technical faults dominate the Pareto, the lever is maintenance, MTBF/MTTR, spare parts management, and root cause analysis – not just repair. When material dominates, the focus is supermarket, kanban, replenishment processes, and material transparency. When changeover dominates, SMED is the approach. When quality and rework dominate, the focus is on process capability, inspection planning, and poka yoke. When organization and planning dominate, the levers are shift handover, release processes, and order planning.

A MES that connects the downtime reason catalog, machine data, and action management closes the loop: stoppages are captured, analyzed, assigned to an action, and the impact becomes visible in the next review.

FAQ

How many downtime reasons are optimal? 20 to 40 reasons to start. Sufficient for a Pareto that triggers action, few enough that operators select confidently. Expand only once data quality is stable and "other" stays below 10%.

What is the difference between a downtime reason catalog and a fault catalog? Both terms are used interchangeably. In some systems, a stoppage catalog includes planned stoppages such as breaks and maintenance, while a fault catalog focuses on unplanned events. What matters is the internal definition – not the label.

How does a downtime reason catalog integrate with a MES? In the MES, the catalog is the foundation for downtime capture at the terminal. When a machine stops, the selection appears directly at the shop floor client. Machine data and operator input are combined – creating OEE analytics that can be drilled down by category, line, shift, and time period.

Who maintains the downtime reason catalog? Typically production management or the CI manager, in coordination with maintenance and quality. The catalog should be reviewed at least quarterly: what keeps landing in "other"? Which reasons are never selected? Which new events are missing?