Downtime tracking software: the 8 reason codes that actually drive OEE
You can buy downtime tracking software for 200 euros a month or 20,000 euros a month. The price does not tell you much about how useful it will be on Monday morning when the line stops and the shift lead has 30 seconds to type something into a tablet before the next part hits the conveyor.
What matters is whether the software helps the people on the floor name the right reason. That is the whole job. If the reason codes are too vague, the OEE report at the end of the month tells you the line was down for 14 hours and nobody knows why. If the reason codes are too granular, the operator gives up and picks "other" 80 percent of the time. You end up paying for a system that captures nothing.
This guide is the practical version. It covers the eight downtime reason codes that actually drive OEE in a small or mid-sized plant, the 30 you can safely skip, what an iPhone-based downtime feed looks like once it is live, and how to choose downtime tracking software without falling for the demo.
Why most downtime tracking misses the point
Three patterns show up again and again when we audit downtime data from new customers.
The first is "other" inflation. A plant runs 24 reason codes. The top three by frequency are "unplanned stop," "minor issue" and "other." Together they account for 62 percent of recorded downtime. That data is useless for root-cause work. It tells you the line stopped but nothing about what to fix.
The second is double counting. Operators log a stop in the MES, a separate stop in the maintenance system, and a third entry in a paper logbook for the shift handover. The numbers never reconcile. The plant manager picks whichever source supports the argument they want to have at the production meeting.
The third is delayed entry. The line stops at 09:12. The operator logs it at 11:47 when they get back to the tablet. By then they remember the duration as "about 20 minutes" instead of the actual 8 minutes and 14 seconds. Real-time monitoring becomes after-the-fact storytelling.
The fix is not more reason codes. It is fewer reason codes, captured at the moment the line stops, with enough context that the next person can act on it.
The 8 reason codes that matter (and the 30 that don't)
Across roughly 40 plants we have worked with in the last 18 months, the same eight reason codes account for 85 to 92 percent of all downtime minutes. The other 30 plus codes that vendors love to put in the default template account for the rest. Track the eight. Make the rest free-text or roll them into "other."
The eight codes that actually drive OEE are:
- Material starvation. No parts at the infeed. Either upstream is slower than your line or the kit was not staged in time.
- Material jam or quality reject upstream. A part is at the infeed but it is wrong, damaged, or stuck. Different cause from starvation, different fix.
- Tool change or recipe change. Planned changeover between SKUs. Track this separately so it does not pollute unplanned downtime.
- Mechanical fault. A physical part of the machine has failed. Bearings, belts, pneumatics, anything that needs a technician.
- Electrical or control fault. The mechanical parts are fine but the PLC, sensor, or drive threw an error. Different troubleshooting path.
- Operator absent or break. The line is ready but nobody is at the station. Includes shift handover gaps and unplanned breaks.
- Quality hold. The line is stopped because the last few parts failed inspection and someone needs to decide what to do.
- Upstream or downstream blockage. Your line is fine but the conveyor is full because packaging is behind, or the warehouse cannot accept more pallets.
That is it. Eight codes covers the vast majority of what shifts the OEE number. Everything else is either a sub-category of one of these or a tail event you can capture as free text once a month and review during the OEE review.
The reason this works is that each of the eight codes maps to a different action. Material starvation calls planning. Mechanical fault calls maintenance. Quality hold calls the quality team. If your reason code does not tell the operator who to call, it is the wrong reason code.
What an iPhone-based downtime feed looks like
If you have read our OEE calculation guide you know that downtime data feeds availability, which is one of the three OEE pillars. The data only matters if it is captured the moment the line stops.
The classic approach is a tablet wired to the PLC. When the PLC throws a stop event, a pop-up asks the operator to pick a reason code. This works but it costs about 4,000 to 8,000 euros per line for hardware and integration, and it locks you into whatever PLC vendor you started with.
The iPhone-based version skips the PLC integration entirely. A refurbished iPhone is mounted at each station running a single app. The camera watches the line. When the part flow stops for more than a configurable threshold (usually 8 to 15 seconds depending on cycle time) the app flags it and the operator picks one of the eight reason codes on screen. The whole interaction takes under 5 seconds.
Three things make this work that did not work five years ago. First, the iPhone camera is good enough to detect cycle stops reliably in plant lighting without a separate sensor. Second, on-device processing means the data is private and there is no latency from cloud round trips. Third, the operator is already comfortable with the interface. There is no training overhead beyond "tap the reason."
Hardware to get a line running with this approach stays under 1,000 euros per station: refurbished iPhone, mount, ring light, ethernet adapter for the data backhaul. You can have a downtime feed on three lines in an afternoon.
From log to action: building a shift-level downtime workflow
Capturing the data is half the work. The other half is making sure the data triggers something before the shift ends.
The workflow we see working consistently in plants with real OEE improvement looks like this. Every reason code logged in the last hour shows up on a shared shift dashboard. The shift lead glances at it during the 15-minute walk. If material starvation has been logged three times in two hours, planning gets a Slack message before lunch, not at the next planning meeting on Thursday. If mechanical faults are clustering on one machine, maintenance gets paged for a look before the next scheduled PM window.
The dashboard does not need to be fancy. A single page with the eight codes, count and minutes for the current shift, and a sparkline showing the trend versus last week is enough. What matters is that the shift lead actually looks at it, and that the act of looking triggers a conversation.
At the end of each shift the lead writes two sentences in the handover: what the biggest downtime driver was and what they did about it. This becomes the data that the production meeting on Friday actually uses. The OEE number on the wall is a lagging indicator. The two-sentence handover is the leading one.
For the camera-based version of this workflow, see our piece on camera-based production monitoring which covers the vision pipeline in more detail. For shift handover templates that pair with this data, see shift handover for process engineers.
Choosing downtime tracking software
When you sit down to evaluate downtime tracking software, most demos will dazzle you with dashboards and AI assistants and predictive maintenance modules. Ignore the demo. Ask five questions.
First, how long does it take to log a stop from the moment the line goes down? If the answer is more than 10 seconds of operator time per event, the data will be late and incomplete within a month.
Second, how many reason codes are configured by default and can you reduce them to eight? Vendors who insist on their 40-code taxonomy do not understand machine downtime tracking on a real shopfloor.
Third, does the system work without a PLC connection? If the only path to capture downtime is to integrate with your control system, you are buying a three-month implementation project before you see any data. Camera-based or button-based capture should be a first-class option, not an upsell.
Fourth, what does the data look like raw? Ask to export a CSV of one week of downtime events from an existing customer (anonymized). If the vendor cannot do that in five minutes, the data is locked in their dashboard and you will fight to get it out when you want to do your own analysis.
Fifth, what is the total cost per line for year one, including hardware, integration, training, and the subscription? Most teams budget for the license and forget the rest. A 200-euro-a-month subscription with 12,000 euros of integration is not a 2,400-euro-a-year decision.
The right downtime tracking software is the one your shift leads use without being told to, your maintenance team trusts the data from, and your CFO does not need to write off as a sunk cost in year two.
FAQ
What is the difference between downtime tracking and OEE software? OEE software calculates the full OEE number using availability, performance, and quality. Downtime tracking software focuses specifically on the availability pillar by capturing why the line was down. Most teams need both, but you can run downtime tracking on its own and add the performance and quality pieces later. For the full calculation, see our OEE calculation guide.
How granular should reason codes be? Eight to ten codes is the sweet spot. Below six and you cannot separate planning issues from mechanical issues. Above twelve and operators default to "other" within two weeks. Resist the urge to add a code every time someone in a meeting suggests one.
Can you do downtime tracking without a PLC? Yes. Camera-based capture using a mounted iPhone is the cleanest option for plants without modern PLCs or for retrofitting older lines. Button-based capture (a physical button at the station the operator presses when the line stops) works too, though it adds about 2 seconds of operator time per event.
How fast can you get downtime tracking software live? For an iPhone-based capture system you can have one line running in an afternoon and a full plant of 8 to 12 lines running in under a week. PLC-integrated systems typically take 6 to 12 weeks per line including testing.
Does downtime tracking software replace your CMMS? No. A CMMS handles work orders, parts inventory, and PM schedules. Downtime tracking handles real-time event capture and reason coding. The two should talk to each other so that a mechanical fault logged on the line creates a draft work order in the CMMS automatically, but they solve different problems.
One framing question that comes up often is how downtime tracking software connects to wider overall equipment effectiveness reporting. The downtime feed is the availability input that feeds into OEE. Without a clean source for both unplanned and planned downtime events, the availability number in your weekly OEE report is a guess, and the team ends up arguing about which line was worst instead of fixing it. With a clean feed, the same number becomes the input every root cause analysis conversation starts from, and the weekly review shifts from blame to learning. Reason-coded events lift uptime over a quarter because shift leads finally have the data to fix the biggest losers first.
The reporting cadence that earns its place is weekly downtime reporting tied to a Pareto chart of reason codes, with mean time to repair (MTTR) and OEE scores trended alongside production losses for each line. The reason categories you set up should cover equipment failure, slow cycles, quality issues, and scheduled maintenance separately, so the weekly review can see which category is growing fastest. A continuous improvement programme that draws on that data has a way of staying focused on the biggest losers instead of the loudest ones. Teams that build the muscle of weekly review on a clean feed see the difference inside a quarter.
Get downtime tracking live this week
If you want a downtime feed running on one line by Friday, the fastest path is a refurbished iPhone, a mount, and a free Enao account. Pick the eight reason codes that fit your plant, point the camera at the line, and you have data flowing in under an hour. No PLC integration, no 12-week project, no five-figure invoice.
Start free or join the community to compare reason code templates with other process engineers who are doing the same thing.
