HelpFab

A practical machine downtime reason code list

Your reason code list is the single most important decision defining downtime, and what most shops get wrong. Build it too specific and everything gets logged as "Other." Build it too vague and your Pareto lumps three different problems into one bar. Build it in free text and the same failure gets spelled four ways by four operators.

This is a starter list you can adapt in an afternoon: a short, structured list of machine downtime reason codes, split into planned and unplanned downtime, with real fault-code examples for each. If you have not yet decided what counts as downtime or who logs it, read how to track machine downtime first — the code list only works once the definition underneath it is built.

Why the code list is the whole game

A reason code is the answer to one question: why was the machine not making good parts? Every report you will ever build — Pareto by minutes, Pareto by event count, planned-versus-unplanned trend — is just those codes counted and sorted. If the codes are wrong, every report downstream is wrong too, and no amount of charting fixes it.

Two rules matter more than the list itself:

Keep the list under fifteen codes for the first year. Cover the big buckets, force everything else into an "Other" code with a mandatory note, and mine those notes for the codes you are missing.

  • Structure over free text. An operator picking from a fixed list produces data you can use. An operator typing a note produces info you have to clean. Mech, mechanical, mech fail, and bearing are four rows that are one cause.
  • Short over complete. A list of ten codes that operators use correctly beats a list of sixty that they abandon. You can always split a code later; you cannot un-confuse someone who faced sixty options at 2am.

The starter taxonomy

Here is a twelve-code list that fits most manufacturers — machining, stamping, molding, assembly. The top level is the split that drives your most important report: planned downtime is scheduled and often unavoidable; unplanned downtime is what you attack first.

A few deliberate choices in that list:

  • Changeover is planned, not a breakdown. It is usually the biggest single bucket of downtime, and it is a SMED problem, not a maintenance one. Mixing it in with failures hides both.
  • Mechanical and electrical are separate codes. They route to different people. A maintenance tech and a controls tech do not fix the same thing, so do not make them share a bar on your Pareto.
  • "Waiting" is its own code. Blocked-and-starved time is not the machine's fault, and lumping it into a machine failure code sends you chasing the wrong asset.
  • "Other" always carries a note. That note field is how the taxonomy grows. When "Other" comments cluster on one cause three months running, promote it to a code of its own.

Grounding codes in real fault codes

The reason code is the human-readable category. The fault code is the machine-level trigger underneath it. You want both: the reason code for reporting, the fault code for diagnosis. Exact fault codes vary by controller and vendor, so treat these as illustrative of the mapping, not a universal list — check your own HMI's alarm history for the strings your machines actually emit.

The point is not to memorize alarm strings. It is that when an operator selects "Electrical / controls fault" and the note says "SV0410, X-axis," maintenance walks up already knowing where to look. The reason code aggregates; the note diagnoses.

  • A servo alarm on a CNC (Fanuc's SV-series alarms, for example) maps to Electrical / controls fault.
  • An overload or thermal trip on a drive maps to Mechanical failure if it is a jam and Electrical / controls fault if it is the drive itself — the operator's note disambiguates.
  • A misfeed or tool-breakage sensor on a press maps to Tooling / die failure.
  • A guard-open E-stop maps to Mechanical failure or Other depending on why the guard opened; the note decides.

A worked example: cleaning up one week of raw notes

Here is why structure beats free text, using one week on an injection molding machine running a single shift, five days. Scheduled run time was 40 hours. The operator logged stops as free-text notes, the way most shops start. Here is the raw list, verbatim:

Seventeen events, but eleven different labels. A pivot table on that raw text produces eleven bars, none of which is actionable. Now map each note to the starter taxonomy:

That is 8.9 hours of downtime against 40 scheduled hours — availability of 77.8%. And now the data actually says something:

Same week, same stops. The only thing that changed is that the stops were coded to a fixed list instead of typed as prose. That is the entire value of a reason code taxonomy.

  • changeover x6, mold change, setup new job — 6 events, 210 min
  • screw not filling, short shots QC hold — 2 events, 55 min
  • heater band alarm, zone 3 temp fault, controls — 3 events, 90 min
  • no resin, hopper empty, waiting on material — 4 events, 80 min
  • PM, greased — 1 event, 30 min
  • break, lunch — covered separately
  • hyd leak, pump — 1 event, 65 min
  • Changeover is 39% of downtime and it is planned. Six mold changes averaging 35 minutes. This is not a breakdown to fix; it is a setup-reduction opportunity. Shaving each changeover by ten minutes returns an hour a week.
  • Controls faults and material shortage together are a third of downtime, and neither is a "machine" problem in the usual sense. One is a temperature-control tuning issue; the other is scheduling and inventory. Free text buried both; the taxonomy surfaces them.
  • The single hydraulic event is only 65 minutes but it is the worst event by duration. One code, one event, worst per-occurrence — exactly the kind of thing that hides inside a generic "maintenance" bucket and never gets a root-cause conversation.

Rolling it out without killing compliance

A good list dies fast if the rollout is clumsy. A few guardrails:

  • Start with your two worst machines, not the whole plant. Prove the codes work where the pain is, then copy the list outward.
  • Laminate the list at the machine. Twelve codes on a card by the HMI beats a code buried three menus deep.
  • Review "Other" monthly. It is your backlog of missing codes. Promote clustered notes; retire codes nobody ever picks.
  • Never let the codes become a blame tool. The moment operators believe reason codes are used to grade them, the codes become fiction. Measure the process, say so out loud, and act like it.
  • Do not round durations. Estimated times cluster on :00 and :30 and wreck your averages. Capture actual start and stop, ideally stamped by the tool rather than typed.

Where HelpFab fits

A reason code list is only as good as the thing enforcing it. In HelpFab's Issues and downtime tracking, you set up your own configurable issue categories and types — this taxonomy becomes the pick-list an operator sees on a phone or tablet, so a cause is spelled one way every time. The Issue Reports page then builds the Pareto and trend views over any date range straight from those codes, with no pivot tables to rebuild, and reminders turn the top code into a follow-up instead of just another bar on a chart.

But the tool is the last step, not the first. Settle the definition, adopt a short list like the one above, run it on two machines for a month, and let the "Other" notes tell you what to add. A code list that already works is the best thing you can bring to any downtime software.