Downtime codes in a CMMS are a short, standardized list of reasons that a technician or operator selects every time an asset stops. Done well, they turn “the line was down” into data you can rank, trend and act on. Done badly, they become a dropdown full of “Other.” This guide shows how to structure the list, what to capture with each code, how to report on it, and how the same data connects to MRO inventory turns.
TL;DR
- Keep downtime (an operational measure) separate from failure (a maintenance diagnosis). Record each in its own field so neither gets distorted.
- Use a short list of codes that do not overlap, describe the machine rather than the person, and include a catch-all that you review and break down on a schedule.
- Capture the asset, start and end time, equipment status, labor hours and cost, and split waiting time (parts, technician, approvals) from hands-on repair.
- Use the code to trigger action, such as a work order, an escalation or a root-cause review.
- Feed the same data into spare-parts decisions: repeat parts-related downtime and slow or fast MRO inventory turns tell you where stock is wrong.
Table of Contents
- What downtime codes are and why they matter
- Downtime codes, failure codes and problem codes
- A practical structure for your code list
- What to capture with every code
- Make the code trigger something
- Reporting on downtime codes
- Where MRO inventory turns come in
- Rollout: how to introduce codes without a revolt
- Perspective: what we see in practice
- Put your downtime codes to work in MPulse
- FAQ
- Sources
What downtime codes are and why they matter
A downtime code (also called a downtime reason code) answers one question: why was this asset not available? It is applied to an event with a start time, an end time and an asset. Over a quarter, those events add up to a ranked picture of where hours are lost.
Without codes, the free-text notes on work orders are the only record. Free text is hard to filter, and two technicians describe the same problem in different words. A code list gives your reports a common vocabulary, which is what makes trend analysis, cost allocation and audit records possible.
The maintenance side of this has a long professional history. The North American Transmission Forum describes a CMMS as software that keeps maintenance-operation information so workers can do their jobs more effectively, and its equipment problem coding process starts at the moment a corrective-maintenance need is recognized and a work order is created. In other words, the code belongs to the work order from the first minute, not as an afterthought during closeout.
Downtime codes, failure codes and problem codes
Teams often mix these up, and the confusion produces unreliable reports.
- Downtime codes describe why production or service stopped. They are an operational measure.
- Failure codes describe how the equipment failed and what was done about it. They support maintenance analysis.
- Problem codes record what the technician found in the field.
The two are not the same thing. Guidance on enterprise asset management points out that not every downtime event is caused by a failure, and not every failure produces downtime. A planned changeover is downtime with no failure. A worn bearing caught during a scheduled inspection is a failure with no lost production.
The NATF model goes a step further and separates the observed deficiency, the component and the problem code. Deficiency codes describe how the equipment failed. Problem codes describe field findings such as damage, corrosion, leaks or an improper position. The practical lesson is to have technicians record what they observed, and leave engineering conclusions to a later step. That keeps the field data reliable even when the root-cause theory changes.
For a deeper look at the failure side, see our guide to CMMS failure codes for plant teams, which covers a 90-day pilot of a small code set.
A practical structure for your code list
There is no single universal list, and a hospital, a food plant and a university campus will not share one. The structure below works as a starting point.
Level 1: the event category
Start with a handful of broad categories that every event falls into:
- Planned: scheduled preventive maintenance, inspections, calibrations, changeovers.
- Unplanned equipment: mechanical, electrical, controls or instrumentation faults.
- Waiting: parts, technician, permit or approval, contractor.
- Operational: no material, no operator, upstream or downstream blockage.
- External: utility loss, weather, supplier or regulatory hold.
Level 2: the specific reason
Under each category, add the specific reasons your people actually see. For unplanned equipment, that might be motor failure, sensor fault, hydraulic leak, belt or chain failure, software or PLC fault, and operator adjustment. Use the language your technicians already use, so choosing a code takes seconds.
Rules that keep the list usable
- Keep it short. Every extra code adds burden for the person at the machine. If a code is used a handful of times a year, merge it into a neighbor.
- Make codes mutually exclusive. If two codes could describe the same event, people will split their choices at random and your Pareto chart will lie.
- Describe the machine, not the person. Codes that point at people (“operator error”) get avoided or misused. Describe the condition instead, such as “incorrect setup” or “missing standard work.”
- Include an “All Other” code, and review it. A catch-all lets people keep working, but if it becomes one of your biggest categories, break it down into new specific codes.
- Review the list regularly. Quarterly works for most teams. Retire codes nobody uses and add codes for patterns you keep seeing.
These rules reflect widely shared practice in downtime tracking. They matter more than the exact number of codes, though a list that fits on one screen is a good test.
What to capture with every code
A code on its own says little. The data around it determines whether reports are useful. A U.S. Department of Energy national laboratory report on CMMS data for wind turbines recommends capturing the machine ID, event type, failure-mode ID and name, equipment status, event date and time, man-hours, total downtime and cost data. The same fields apply to a pump, a chiller or a packaging line.
The most valuable recommendation in that report is to split downtime into its parts: active maintenance, time waiting for parts, time waiting for a technician, administrative delays and logistics delays. Labor hours alone do not explain why equipment was unavailable. A four-hour outage might contain forty minutes of wrench time and three hours waiting for a part that was not in the storeroom. Those two stories call for completely different fixes.
This breakdown also helps when the cause sits in the control system rather than the mechanics. If a processor is overloaded by its tasks and trips the line, the RSLogix 5000 task monitor tool can help confirm the cause before you assign the code, so the event is not logged as a generic electrical fault.
A sample event record
| Field | Example entry |
|---|---|
| Asset | Packaging line 2, case sealer |
| Category | Unplanned equipment |
| Downtime code | Sensor fault |
| Start / end | 6:10 a.m. / 9:40 a.m. |
| Active repair | 35 minutes |
| Waiting for part | 2 hours 15 minutes |
| Waiting for technician | 20 minutes |
| Labor hours / parts cost | 0.6 hours / part and labor recorded on the work order |
| Follow-up | Add spare sensor to storeroom, review min/max |
If you want to learn how total downtime is calculated and the figures that go into it, read how to calculate downtime.
Make the code trigger something
A code that is only recorded is a missed opportunity. Decide in advance what each category sets in motion:
- Unplanned equipment, high criticality: automatic work order, notification to the supervisor and escalation if no one responds.
- Waiting for parts: alert to the storeroom or buyer, and a flag for review of min/max levels.
- Repeat reason on the same asset: a root-cause review and a corrective action.
- Compliance-related stop: a record in the regulatory file with the time, the cause and the person who signed off.
The DOE Operations and Maintenance Best Practices Guide lists the CMMS capabilities that make this possible: equipment-level work order history, scheduled and unscheduled maintenance tracking, real-time activity reporting, labor and material cost tracking and automated inventory reorder. If your system already does these, adding a code is a small step that changes what the data can do.
For regulated sites, the same records support audit readiness. Our article on CMMS and compliance explains how asset history, automated preventive tasks and inspection checklists fit together.
Reporting on downtime codes
Once a few months of coded events exist, a short set of reports answers most management questions.
- Pareto by code. Total hours by reason. This shows where the biggest losses are, and it is the first chart to present to leadership.
- Pareto by asset. The same data sorted by equipment. A few assets usually account for a large share of the hours.
- Active repair versus waiting. If waiting time dominates, the problem is logistics, staffing or parts, not wrench skill.
- Planned versus unplanned ratio. A rising planned share, with falling unplanned hours, is the sign that preventive maintenance is working.
- Repeat events. The same code on the same asset within a short window points to a repair that did not address the cause.
The DOE report, based on a survey of 558 companies using a CMMS, found average increases of 28.3% in maintenance productivity and a 20.1% reduction in equipment downtime. It is an older survey, so treat it as an indication of direction rather than a promise for your site. The results come from consistent data capture plus action on it, which is exactly what coded downtime provides.
Once you know which assets and reasons dominate, you can schedule maintenance more intelligently to attack them. Condition-based triggers are another option, as described in the MPulse help on condition-based maintenance.
Where MRO inventory turns come in
Many of the longest events in a downtime report are not repairs. They are waits for parts. That is why downtime codes and storeroom metrics belong in the same conversation.
MRO inventory turns measure how many times your storeroom stock cycles through in a period. The common calculation is the total value of parts issued divided by the average inventory value, where average inventory is the mean of the beginning and ending on-hand values. For example, if a storeroom issued $600,000 of parts in a year and averaged $400,000 on the shelf, it turned 1.5 times.
Turns alone do not tell you whether stock is right. A low number can mean you hold too much slow-moving inventory. A high number can mean a lean, well-managed room, or it can mean you keep running out. Pair turns with your downtime data:
- High “waiting for part” hours on critical assets suggest those parts need higher minimums, whatever the overall turns look like.
- Many parts with zero issues in a year suggest you can reduce stock, transfer it or stop reordering.
- Repeat failures that consume the same part suggest a min/max level based on actual usage rather than a guess.
Research supports sorting spares by consequence. An MIT thesis on internal spare parts management notes that MRO spares have intermittent demand, varied prices and lead times, and potentially large downtime costs, and recommends criticality classification plus forecasting to set stocking policy. It reports that improved safety-stock settings found inventory savings of up to 39% while keeping or raising service levels for critical parts.
A U.S. paper-mill case study from a pump manufacturer shows the same logic in practice. Its inventory audits combined criticality, historical usage and supplier lead time, and five mills saved more than $500,000 by reducing unnecessary on-site spares and transferring parts between mills.
PNNL’s guidance on reliability-centered maintenance adds a useful framing: failure consequences include operational, non-operational, safety and environmental effects, and can be quantified with downtime, backlog, budget and spare-parts-inventory metrics. That is the case for tracking both sets of numbers side by side.
A simple monthly routine
- Pull the top five assets by downtime hours.
- For each, separate the hours waiting for parts from active repair.
- List the parts involved, then check on-hand quantity, min/max and lead time.
- Raise minimums where a stockout caused a long wait on a critical asset.
- Lower or retire stock for parts with no usage and no criticality.
- Recalculate turns next quarter and compare it with the downtime trend.
Rollout: how to introduce codes without a revolt
The biggest risk is not the software setup but whether people use the codes honestly.
- Pilot first. Start with one area or one shift and a small list. Adjust after a few weeks.
- Involve technicians and operators when drafting the list. They know the real reasons, and they will use codes they helped write.
- Make the field required, but make it quick. A mobile screen with a dropdown beats a form back at the desk.
- Show people the results. When the team sees a code lead to a fixed problem, quality of entries rises.
- Audit a sample. Each month, read a dozen events and check that the code matches the description.
Perspective: what we see in practice
We see the same pattern at many sites: the code list is not the hard part. The hard part is using what it tells you.
A short, well-defined list that technicians trust will outperform an elaborate one that no one respects. We recommend starting with a pilot, keeping the catch-all under review, and splitting repair time from waiting time from the first day. That split alone often changes the conversation from “we need more technicians” to “we need the right part on the shelf.”
MPulse is designed to keep these records connected: work orders, asset history, preventive schedules, inventory and reporting live in one system, with a calendar interface that makes planned downtime visible. Our customers use that connected data to move from reacting to failures toward planning around them. Where compliance matters, the same records serve as audit evidence.
The goal is not more data. It is fewer surprises.
Mark
Put your downtime codes to work in MPulse
MPulse CMMS brings work orders, asset tracking, preventive maintenance scheduling, parts inventory and graphical reporting together, so the codes you define feed the reports you need. Plans start with Professional at $29 per month per user, with Advanced at $79 per month per user; see current options on our pricing page. If you want help setting up code lists, importing existing records or training your team, our implementation, consulting and training services are built for that.
Teams that need to connect other systems can look at the DataLink integration add-on for moving data between MPulse and ERP or other platforms.
FAQ
How many downtime codes should we have?
As few as will cover your real events, so operators can find the right one quickly. Start with a pilot list of roughly ten to thirty reasons, then merge rarely used codes and split any catch-all that grows large. Review the list quarterly.
What is the difference between a downtime code and a failure code?
A downtime code explains why an asset was unavailable, and a failure code explains how the equipment failed. They overlap but are not identical: not every downtime event is a failure, and not every failure causes downtime. Record both in separate fields.
What are the different types of downtime?
The most useful split is planned versus unplanned. Planned downtime covers preventive maintenance, inspections and changeovers. Unplanned downtime covers breakdowns, waits for parts or people, and external events such as utility loss. Within each, separate active repair from waiting time.
How do downtime codes relate to MRO inventory turns?
When a large share of downtime hours is coded as waiting for parts, your stocking levels are probably wrong for the assets that matter most. Inventory turns show how fast stock cycles through the storeroom. Read the two together: raise levels for critical parts that cause long waits, and reduce stock that never moves.
Can a CMMS create work orders from downtime codes?
Yes, where the system is configured to do so. You can set specific codes, such as a critical asset failure, to create a work order, notify a supervisor or require follow-up. Check the configuration options in your own CMMS.
Sources
- NATF Equipment Problem Coding Process
- Better/Best Practices for MAXIMO
- Wind Energy Computerized Maintenance Management System (OSTI)
- Operations & Maintenance Best Practices Guide: Release 3.0 (U.S. DOE)
- A systematic approach to internal spare parts management (MIT)
- ITT Goulds paper-mill inventory case study
- An Advanced Maintenance Approach: Reliability Centered Maintenance (PNNL)
- RSLogix 5000 Task Monitor Tool
