Key takeaways
- The downtime you can hand-log is the downtime that already gets attention. The losses that hurt most, small stops and slow cycles, are too brief and frequent to write down, so they never enter the log.
- Good tracking starts with clear stop states, running, planned stop, unplanned stop, then captures every stop automatically with its start, end and duration.
- A stop count without a true cause is just a tally. Pair automatic capture with a record of what physically happened so fixes target the real cause, not the easiest to blame.
- Tracking only pays when it drives action: a Pareto of causes, a cost per stop, and a fast loop from a tracked stop to a completed fix.
Ask a plant how much downtime it has and you usually get a figure from a paper log or a spreadsheet, and that figure is almost always too low. Not because anyone is lying, but because the biggest losses are the ones nobody can write down fast enough. Tracking downtime well is less about the form you fill in and more about catching the stops a form will always miss. This guide walks the practical steps, from defining what counts as a stop to closing the loop from a tracked event to a fix, so the number you report is the number that is really happening on the floor.
Step 1: Define what counts as downtime
Before you capture anything, agree on the states. The simplest scheme that works is three: running, planned stop and unplanned stop. Planned stops are changeovers, scheduled maintenance and breaks; unplanned stops are breakdowns and the short unplanned stoppages in between. Then attach a short reason list to the unplanned bucket, short enough that people actually use it consistently, because a fifty-item dropdown gets ignored. Mapping your stops to the six big losses keeps the categories honest, and deciding up front how you treat planned versus unplanned downtime stops the arguments later.
Step 2: Capture every stop, not just the ones you can write down
This is the step that decides whether your tracking is worth anything. Manual logging catches the long, dramatic stops and misses everything else, and everything else is often the bigger number. A thirty-second jam that repeats ten times an hour never gets written down, so it never becomes data, yet it can out-cost the breakdown that filled a whole line on the report. The fix is automatic capture: read every stop straight from the machine, its PLC or a sensor, with a start, an end and a duration, so nothing depends on someone reaching for a pen. Those brief, frequent stoppages are the micro-stops that manual tracking is blind to. The free OEE Tracker is a simple way to start capturing stops without a project.
Step 3: Categorize by reason and find the true cause
Once stops are captured, tag each one with a reason and run a Pareto. A handful of causes almost always produces most of the downtime, and that is where the effort goes. But a reason code is not a cause: knowing a station stopped twenty times labelled jam does not tell you why it jammed. For the frequent few, you need a record of what physically happened, which is where a video or vision record beats memory, so the fix targets the real mechanism rather than the one easiest to blame. The discipline of root cause analysis turns the Pareto into permanent fixes, and the hidden factory calculator shows how much those frequent stops are quietly costing.
Step 4: Turn the data into a number that drives action
Downtime data changes nothing until it becomes a decision. Three numbers do the work: a ranked Pareto that says what to fix first, a cost that says how much it is worth, and the OEE impact that ties it to the plant's headline metric. The downtime cost calculator converts hours lost into money so the case is fundable, and the OEE calculator shows how the tracked stops pull availability, and therefore OEE, down. A tracked stop with a euro figure next to it gets fixed; a tracked stop in a report nobody reads does not.
The free OEE Tracker captures stops and turns them into OEE, no project required.
Step 5: Close the loop from a tracked stop to a fix
Tracking that ends in a report changes nothing on the floor. What makes it pay is the loop: a tracked stop becomes a prioritised, routed work order, the fix gets done, and you confirm it held so the same stop does not return next week. Most tracking efforts stall here, with a tidy dashboard and a stubborn downtime number, because capturing a stop and closing it are two different jobs. Tracking is the start of the work, not the end of it, and the value only lands when the data reliably turns into completed fixes.
The partner we recommend for closing that loop is Fabrico, because it was built to make downtime data act on itself. It reads OEE and every stop straight from the machine's PLC and uses computer vision to show the true cause of each micro-stop and slow cycle on video, then closes the loop from that signal to an auto-routed work order, so a tracked stop becomes a scheduled fix instead of a line on a report. It is EU-built with EU data residency and holds ISO 27001, 20000-1 and 9001 (which supports audit-readiness). The tools and guides here stay free either way; Fabrico is what we point to when a team wants downtime tracking that actually closes the loop. Book a Fabrico demo to see the true-cause capture on your lines.
FAQ
Why is manual downtime tracking unreliable?
Because the losses that matter most are too brief and frequent to write down. A breakdown gets logged, but a thirty-second jam that happens ten times an hour does not, so manual logs systematically understate downtime and miss the small stops that often add up to the largest loss. Hand logging also relies on memory for the cause, which produces fixes for the easiest cause to blame.
What should I track for each stop?
At minimum the start, end and duration, the line or asset, and a reason code from a short, disciplined list. The most valuable addition is a record of what physically happened, from the PLC and ideally video, because that is what lets you find the true cause. Keep the states simple: running, planned stop, and unplanned stop broken down by reason.
How do you track micro-stops?
Not by hand, because they are over before anyone can record them. The only reliable way is automatic capture from the machine, reading stops from the PLC or a sensor so every stoppage is logged whether it lasts thirty seconds or thirty minutes. Adding computer vision shows what happened during each, so the frequent few can be found and fixed.
What is the difference between downtime tracking and OEE?
Downtime tracking captures the individual stop events, when, how long and why. OEE is the summary metric that rolls those losses, plus speed and quality losses, into one percentage. Tracking is the raw data; OEE is the scoreboard built from it, and it is only as honest as the stop data underneath.
Related: free OEE Tracker · micro-stops · downtime cost calculator · reduce unplanned downtime · OEE data collection methods