Downtime is the most visible loss on any shop floor — a stopped machine is obvious to everyone. But not all downtime is equal, and treating it as one big number hides the part you can actually do something about.
The key distinction is planned vs. unplanned. Get that split right and you'll know which stops to schedule around and which to hunt down.
What's the difference?
Planned downtime is time the machine is intentionally not producing — you knew about it in advance and chose it:
- Changeovers and setups
- Scheduled (preventive) maintenance
- Breaks and shift handovers
- No demand / no orders scheduled
- Planned trials and validation runs
Unplanned downtime is time you lost that you didn't choose — the machine should have been running, and wasn't:
- Breakdowns and equipment failures
- Material or component shortages
- Operator or tooling unavailability
- Unplanned quality stops
A simple test: was this stop on the plan for the shift? If yes, it's planned. If it surprised you, it's unplanned.
Why the split matters for OEE
The two are not just different in cause — they're treated differently in the maths. Planned, non-production time is usually subtracted from the clock before you measure performance, so it sets the "planned production time." It's unplanned downtime that eats into Availability and pulls your OEE down.
Planned downtime is a cost you manage. Unplanned downtime is a problem you solve.
That's why lumping them together is misleading: a plant can look "busy with downtime" when in fact most of it is necessary changeovers — or it can look fine on average while unplanned breakdowns quietly destroy output. You need to see them apart.
How to track it (without a big system)
You don't need an expensive MES to start. You need consistent downtime reasons, captured at the source:
- Use a short, fixed list of reason codes — not free text. "Breakdown — conveyor", "Changeover", "No material", "Planned maintenance". Twenty good codes beat two hundred messy ones.
- Tag each one planned or unplanned up front. A simple convention — for example, planned codes starting with one letter — lets every report split the two automatically.
- Capture it where it happens — operator entry, a tablet, or the machine itself. Data collected three days later is data nobody trusts.
Turn the data into action
Once stops are coded, two simple analyses do most of the work:
- Pareto the causes. Sort unplanned downtime by reason. Almost always, a handful of causes account for the majority of lost minutes — that's your fix list, in priority order.
- Watch MTBF and MTTR. Mean Time Between Failures tells you how reliable a machine is; Mean Time To Repair tells you how fast you recover. Rising MTBF and falling MTTR is the signature of a maintenance program that's working.
A practical reduction loop
- Measure every stop with a reason code.
- Categorise planned vs. unplanned.
- Prioritise the top unplanned causes (Pareto).
- Fix the root cause of number one — then number two.
- Verify on the trend, and repeat.
The discipline matters more than any single tool. A team that runs this loop every week beats one that buys sophisticated software and never looks at it.
From clipboard to live dashboard
The friction is usually in step one and two: collecting and splitting the data. Production Tracker handles that inside Power BI — it reads your downtime codes and reasons, splits planned from unplanned automatically, and shows the minutes and the Pareto per machine, with no DAX to write. The reduction loop above becomes something you can run from one screen.
The bottom line
Treat downtime as two problems, not one. Schedule the planned, hunt the unplanned, code every stop consistently, and let the Pareto tell you where to start. The minutes you win back are the cheapest capacity you'll ever add.