Planned downtime in OEE is time you deliberately chose not to produce, breaks, scheduled maintenance, and periods with no demand. OEE excludes it from planned production time the metric's denominator. Availability loss, by contrast, is unplanned stopped time during hours you meant to run, and it stays in and lowers the score. Keeping those two straight is most of what separates an honest OEE from a flattering one.
The reason this matters so much is arithmetic. Anything you label “planned downtime” leaves the denominator entirely, so it can never hurt OEE. Anything you label “availability loss” stays in and pulls the score down. That asymmetry is a standing temptation: reclassify a breakdown as planned maintenance and the number improves on its own. This guide draws the line precisely, works a short example showing how mislabeling inflates the score, and gives you a procedure that keeps the two categories from bleeding into each other. The free OEE calculator follows the same split.
What counts as planned downtime in OEE?
Planned downtime is any stop you scheduled in advance because you did not intend to make product. The standard members of the category:
- Breaks and meals time the crew is off the line by design.
- Shift meetings, training, and sanitation windows recurring, calendared, non-production.
- Planned maintenance a scheduled PM window (with the caveat that some plants keep this inside the denominator; more below).
- No demand hours with no orders to run, conventionally handled above the OEE denominator at the scheduled-time cut.
The common thread is intent: you knew in advance the machine would not be making product, and you decided that on purpose. Planned downtime is excluded from planned production time, so it neither helps nor hurts OEE, it simply isn't in the window OEE grades. TEEP is the metric that does count it, which is why a line can post a strong OEE and a weak TEEP at the same time.
Where is the line between planned downtime and availability loss?
The line is intent decided in advance. If you knew before the shift that the machine would be stopped and you meant it, it is planned downtime and it leaves the denominator. If the stop happened during time you intended to run, whether a breakdown, a jam, a material-out wait, or a changeover, it is an availability loss and it stays in. The test is not how long the stop was or whether anyone was annoyed; it is whether you planned not to produce.
Changeovers are the case that trips people up, so state it plainly: a changeover is not planned downtime. You scheduled that time to make product; switching over is how you spent it instead. It stays inside planned production time and lands as an availability loss, specifically one of the six big losses and often the most improvable one, since setup-reduction methods can cut it sharply without capital. Excluding changeovers from the denominator is one of the most common ways an OEE number ends up lying.
Why does mislabeling planned downtime fake a good score?
Because moving a stop from “counted” to “excluded” shrinks the denominator, and a smaller denominator lifts the percentage without a single extra unit leaving the building. It is the purest form of gaming OEE: the floor does not change, only the bookkeeping does.
Watch it happen with hypothetical numbers. A shift plans 450 minutes of production and loses 60 to a breakdown, so run time is 390 and Availability is 390 ÷ 450 = 86.7%. Now the breakdown gets relabeled as a “planned maintenance” window. Those 60 minutes leave the denominator: planned production time becomes 390, run time is still 390, and Availability reads 100%. Nothing improved. The machine broke for an hour either way. But OEE just gained more than thirteen points on the strength of a category change.
This is why a rising OEE always deserves one blunt cross-check: did units shipped rise with it? If the score climbs while output holds flat, a denominator or a label moved, not the process. The defense is definitions fixed in advance and applied without exception, the same discipline that keeps a plant-wide roll-up honest.
Do changeovers and planned maintenance count as planned downtime?
Changeovers never do; planned maintenance sometimes does, by an explicit choice you make once. Changeovers are unambiguous: they consume time you scheduled for production, so they count as availability loss inside the denominator. Treat any argument to exclude them as what it is, a request to hide setup loss.
Planned maintenance is the genuine judgment call. Nakajima's original loading-time definition excluded it, and many plants still do, reasoning that a PM window is time you chose not to run. Others keep it inside the denominator so that output lost to a scheduled PM, especially one that overran, shows up as an availability loss the way any other stop would. Both are defensible. What is never defensible is switching between them opportunistically, or letting a breakdown migrate into the “planned maintenance” bucket at month-end. Pick the convention that makes your downtime tracking honest and freeze it. This gets sharper in campaign plants: in batch production changeovers between grades are frequent and large, so misclassifying them as planned downtime can hide the single biggest availability loss on the line.
How do you handle planned downtime step by step?
Set the categories once, log to them faithfully, and audit for drift. The procedure:
- Write a two-list definition. One list of what is excluded as planned downtime, one of what stays in as availability loss. Put changeovers explicitly on the availability-loss list so no one has to guess.
- Decide the planned-maintenance convention and record it. In or out of the denominator, state which, and why, on the same page. This is the row that gets abused, so make it unambiguous.
- Give every stop a reason code that maps to one bucket. A code should resolve to “excluded” or “counted” automatically, not by the logger's mood at shift end.
- Capture stops as they happen, not from memory. End-of-shift recollection undercounts short stops and blurs categories; log at the machine, ideally from the equipment's own run signal with the operator adding the reason.
- Reconcile planned downtime to the schedule weekly. Excluded minutes should match calendared breaks, meetings, and PM. A week where “planned” time balloons is a week to look for relabeled breakdowns.
- Cross-check OEE against output every period. If OEE rose but units shipped didn't, a denominator or a label moved. Find it before you report the number up.
How does TEEP treat planned downtime differently?
TEEP refuses the exclusion entirely. Where OEE removes planned downtime before the clock starts, TEEP grades against all 168 hours in the week, so breaks, no-demand time, and (depending on your OEE convention) planned maintenance all count against it. The two numbers answer different questions on purpose: OEE asks how well you ran the time you meant to run; TEEP asks how much of your total capacity you converted to good product.
That difference is exactly why planned-downtime honesty matters. You can lift OEE by excluding more time, but you cannot lift TEEP that way, excluded time still sits in TEEP's denominator. When OEE and TEEP diverge sharply, the gap is your unused capacity, and it is telling you whether the constraint is on the running line or in the schedule. See OEE vs TEEP for the full comparison and what counts as a good OEE score for how to read the resulting numbers.
What do the standards say about planned downtime?
Two anchors, stated with their provenance:
- ISO 22400-2:2014 defines the OEE time model and ties Availability to planned busy time planned production time, giving every category a precise definition so two plants cannot disagree on what “planned” includes. See the ISO 22400-2 catalog entry.
- The exclusion of planned maintenance from loading time originates with Seiichi Nakajima's 1980s TPM work. It is the source of the convention, not an audited rule, which is why the maintenance treatment remains a legitimate, plant-by-plant choice rather than a fixed law.
The honest handling of planned downtime is ultimately a data problem as much as a definitions problem. Categories only stay clean if the underlying stops are recorded rather than remembered, which is the case for measuring OEE from machine signals at the source, the way Harmony reads run state directly from PLCs and sensors instead of end-of-shift estimates (see the platform). When the clock is captured automatically, a breakdown cannot quietly become planned maintenance. For a real-floor example, see how one specialty manufacturer replaced paper production logging with real-time visibility then test your own split in the OEE calculator.