“We need better production data and visibility into downtime.” Before that data is any use, every stop needs one of two labels, and everyone has to apply them the same way. This guide gives you a one-line rule for planned vs unplanned downtime, a decision table for the stops people argue about, the effect on OEE, and a way to record both kinds so your downtime reports hold up.
The short answer: planned means scheduled before the shift starts
Planned downtime is time the line is stopped on purpose, put on the production or maintenance schedule before the shift begins, with an expected duration. Someone decided in advance to stop the line, so the rest of the day could be planned around it.
Unplanned downtime is any stop that wasn’t on the schedule when the shift started, plus any planned stop that runs past its scheduled length. It’s time you lost rather than time you chose to spend.
One question settles most arguments: was this stop on the schedule, with a planned duration, before the shift started? If yes, it’s planned up to that duration. If no, it’s unplanned.
Planned downtime examples
- A product changeover that’s on the production schedule
- Scheduled sanitation, clean-in-place (CIP) cycles or end-of-week deep cleans
- Preventive maintenance booked on the maintenance calendar
- Scheduled breaks and meals, if the line stops for them
- Trials, test runs or operator training booked in advance
Unplanned downtime examples
- Breakdowns, motor faults and sensor failures
- Jams and misfeeds that stop the line
- Waiting on materials, packaging or components that should have been there
- No operator or mechanic available when needed
- Quality holds, and unscheduled cleans after a spill or contamination
- The overrun on any planned stop: a 30-minute changeover that takes 50 minutes adds 20 unplanned minutes
Gray areas: is a changeover planned downtime? A decision table
The definitions are the easy part. The arguments start with the stops below. Treat this table as a starting rule set: adjust it to your plant, then write down what you decided.
Two rules sit underneath the table. First, the reference is the schedule as it stood when the shift started, not the schedule as revised at 2 p.m. Second, a planned stop is planned only up to its expected duration; the overrun is a separate, unplanned loss.
Why split an overrun instead of relabeling the whole stop?
Log a 30-minute changeover that took 75 minutes as 75 planned minutes and the 45 lost minutes disappear. Log it as 75 unplanned minutes and a changeover you meant to do looks like a failure. Splitting it keeps both facts: what you planned, and how far you missed.
Planned downtime in OEE: why the classification changes your score
OEE availability compares run time with planned production time. If your rule subtracts planned stops from planned production time, as the example below does, they don’t count against availability. Unplanned stops stay in and pull it down. Some plants deliberately keep changeovers and cleans inside availability so they stay under improvement pressure. Either convention works if it’s written down and used everywhere. What breaks the numbers is moving individual stops from one column to the other.
Example (hypothetical, not client data): one 480-minute shift on a cartoning line, with 30 minutes of scheduled breaks (excluded either way), a preventive maintenance job scheduled for 60 minutes that took 100, and 20 minutes of jams. Planned stops are excluded from planned production time.
Same run time, same output, and a gap of nearly ten points in availability. OEE moves with it, because availability is one of its three factors. Only the right-hand column tells maintenance that the job ran 40 minutes long.
For the formula itself and food-line specifics, see OEE for food and beverage lines. To see what those unplanned minutes cost, enter your own line rate, margin and crew in the downtime cost calculator.
The misclassification trap: when “planned” hides real losses
Every stop filed as planned improves availability and drops off the list of unplanned losses. When OEE is a number someone is measured on, borderline stops drift toward “planned”. Nobody has to fudge anything; loose defaults do the work. Watch for these patterns:
- Overruns absorbed into the plan. A changeover booked for 30 minutes takes 70 and goes in the log as one 70-minute planned changeover.
- “We knew about it, so it was planned.” Material that was running late, or a mechanic tied up on another line, gets logged as planned because someone saw it coming. Knowing a loss is coming doesn’t make it a choice.
- Chronic failures turned into scheduled fixes. A part that fails every week gets a weekly scheduled stop. Planned is the right class, but give it a reason code that marks it as a workaround so it stays on the list of things to fix.
- Operators choosing the class. If whoever is on the line picks planned or unplanned for each stop, the split changes with the person and the shift.
The fix isn’t a perfect definition. Consistency beats the exact rule: a slightly imperfect rule applied the same way on every line and shift gives you trends you can trust, while a perfect rule applied unevenly gives you noise. Write the rule on one page, decide the gray areas once, and take the call out of individual hands.
When you do change the rule, record the date. As the example above shows, a rule change can move availability noticeably overnight, and a chart that mixes two definitions without saying so will mislead whoever reads it next.
How to record planned and unplanned downtime in one log
Planned and unplanned stops belong in the same log, with the same fields, so you can compare them and split a single event into both. These fields make the classification hold up:
Who decides what counts as planned
- The operations or continuous-improvement lead owns the written rule and the gray-area decisions, agreed with maintenance and production.
- An admin, not a developer, maintains the reason-code list: adding, renaming or retiring codes and setting each code’s default class.
- Operators record when a stop started and ended and why. For planned stops they confirm, rather than classify.
- Supervisors review edge cases at the end of the shift, and any edit to a recorded event keeps its history.
Planned stops are easiest to keep honest when they’re entered before the shift from the production and maintenance schedules. The operator confirms the start and end, and anything past the scheduled duration becomes unplanned without a debate.
A spreadsheet can hold these fields for one line. It gets harder with several lines and editors, codes that drift, and history that has to reach a database for reporting. Our guides on how to track production downtime and a SQL Server schema for downtime data go deeper, and the downtime reason codes guide has starter lists for planned and unplanned stops.
Want your rules built into the software?
We build downtime tracking software that applies your reason codes and your planned vs unplanned rules the same way on every shift. Your first call is with an engineer.
What to do with each kind: reduce, schedule better, or accept
Once the two kinds are separated, each gets a different response.
Reduce unplanned downtime
Start with a Pareto chart: total unplanned minutes by reason over a few weeks, then focus on the top few causes. Paste your log into the downtime Pareto analyzer to rank causes and see the planned vs unplanned split, and use the downtime cost calculator to decide which fix is worth paying for.
Shorten and reschedule planned downtime
Planned doesn’t mean fixed. For changeovers, the classic method is single-minute exchange of die (SMED): separate the work that needs the line stopped from the work that can happen while it runs, then move as much as you can into the second group. Sequencing similar products back to back cuts the size of each changeover, and booking preventive maintenance inside a changeover or clean saves a second stop.
Accept what protects the line
Some planned downtime is the price of running safely and shipping good product. Cutting sanitation or preventive maintenance to lift availability can come back later as unplanned downtime, along with quality and safety risk. Track these stops, set standard durations, and hold the line on overruns rather than on the stops themselves.
Using the planned vs unplanned downtime ratio
The planned vs unplanned downtime ratio is planned minutes divided by unplanned minutes over the same period. A higher ratio means more of your downtime was chosen and less was a surprise, which is the direction you want, as long as the classification is honest.
In the maintenance example above, the same shift shows 5:1 when the overrun is logged as planned and 1:1 when it’s split off. That’s why we don’t suggest a target ratio: the number depends heavily on your classification rule, and it can improve simply because stops were relabeled. Use it this way instead:
- Track your own trend with the rule held fixed, rather than comparing against another plant’s number.
- Read it next to total downtime minutes. A better ratio with more total downtime isn’t progress.
- Break it out by line and by reason category, where it points to something you can act on.
- If the ratio jumps, check whether the rule or a reason code’s default class changed before you celebrate.
More practical guides on downtime, OEE and production data are in our guides library.
