A downtime type is the classification of why a work center is unavailable, from planned maintenance that is already out of capacity to an unplanned breakdown that triggers a review, so lost time carries a cause rather than being a blank gap. It tells a planner whether a machine being down was expected or a surprise.
One thing to settle before the definition, because it changes how you use the term. In EDGEBIC the planned-versus-unplanned distinction is entirely real and it drives what you do, but it is not a field you stamp on a scheduling record. The current release has no downtime record and therefore no type picker on one. Where labeled causes genuinely live is the shop floor: a paused job carries a reason code, and reason codes roll up into categories. This entry covers both, and is careful about which is which.
For the wider index of terms, see the manufacturing glossary; for the levels a holiday can apply to, see what is holiday scope in scheduling calendars; and for the underlying block of unavailable time, see what is a downtime event in scheduling.
How it works
At the base level, downtime divides into planned and unplanned, and the difference is when you learned about it.
Planned means maintenance, PM, or changeover known in advance. You take those hours out of the work center's capacity before the plan is built, so the engine never offers them and no job is placed into the window. Unplanned means a breakdown or stoppage: it was not in the plan, it interrupted real work, and the schedule now disagrees with reality until you reschedule the affected steps.
The distinction drives behavior rather than paperwork. Planned downtime is a normal capacity input, so the engine simply plans around it. Unplanned downtime is a disruption, so it prompts a review and a targeted reschedule of what it touched. Same lost hours, very different meaning.
Where the classification is a real field. A richer set of causes exists on the shop floor rather than in the calendar. When an operator pauses a job at the kiosk they select a reason code, and every code sits under one of four categories: machine, material, quality, or waiting. That list is maintainable, ships with a seeded starter set, and is what turns a month of scattered pauses into a ranked picture of where the plant loses time. So if the goal is analyzing causes, reason codes are the mechanism, not a downtime type.
A concrete example
Think of a delivery van being off the road. A booked service appointment is planned: the dispatcher already routed around it, so no drama. A flat tire on the highway is unplanned: it was not in the plan, it stranded a load, and someone has to re-route the remaining stops. The van is unavailable either way, but the two events mean completely different things, and the label is what tells them apart.
Take a work center with a Saturday PM (planned) and a Tuesday spindle failure (unplanned). The Saturday PM was subtracted from capacity when the week was planned, so no job was ever placed there and nothing needs attention. The Tuesday failure happened after the plan was published, so the jobs that were running need review and the remaining steps are rescheduled from where the shop actually stands. Which of the two got a second look was decided by timing, not by a label.
How EDGEBIC uses it
Split it in two, because the two halves live in different places.
On the planning side, planned downtime is expressed as reduced capacity: a per-day capacity override on the work center, shift, and date, carrying the hours the machine can actually work and a free-text reason. The plan then flows around it cleanly. An unplanned breakdown is handled the same way after the fact, followed by a reschedule that moves only what the disruption touched while completed work stays put. There is no type field on either, and no downtime record to attach one to.
On the shop-floor side, the classification is real. Reason codes attached to a paused job roll up under machine, material, quality, and waiting, so a planner can total lost time by cause and target the biggest one rather than treating all downtime as a single undifferentiated loss. That is the difference between knowing the shop loses hours and knowing precisely where, and it is the route to build if analysis is the goal.
To choose which resources a non-working day removes, read what is holiday scope in scheduling calendars; for the block of unavailable time itself, read what is a downtime event in scheduling; and for the codes that carry the cause, read what is a reason code in production tracking.
Expert Q&A: Deep Dive
Q: A machine went down mid-shift and I logged it. Why does that need attention while last week's PM did not?
A: Because of when each one entered the plan, not because of a label on a record. Last week's PM was known in advance, so its hours were taken out of capacity before the week was scheduled and no job was ever placed there: nothing to review. The mid-shift failure was not in the plan and it interrupted real work, so the schedule and reality have diverged and the affected steps need rescheduling from where the shop actually stands. If the operator paused the job at the kiosk with a reason code, that code is what tells you afterward whether it was a machine, material, quality, or waiting cause.
Q: I want to see how much time we lose to meetings versus real breakdowns. Can I get that?
A: Yes, through shop-floor reason codes rather than through a downtime classification on the schedule. Reason codes are their own maintainable list with a seeded starter set, and every code rolls up under machine, material, quality, or waiting, so tagging each pause lets you total time by cause and compare one against another. That turns a vague sense that the shop loses hours into a ranked list you can act on. What you cannot do today is tag a planned capacity reduction with a type, because planned downtime is entered as a per-day capacity override, which carries a free-text reason rather than a classified label.
Frequently Asked Questions
Ready to Transform Your Production Scheduling?
User Solutions has been helping manufacturers optimize their production schedules for over 35 years. One-time license, 5-day implementation.
User Solutions Team
Manufacturing Software Experts
User Solutions has been developing production planning and scheduling software for manufacturers since 1991. Our team combines 35+ years of manufacturing software expertise with deep industry knowledge to help factories optimize their operations.
Share this article
Related Articles
The EDGEBIC Scheduling Glossary Index
A themed index to the EDGEBIC glossary: scheduling engine, capacity and calendars, materials and planning, shop floor, reporting, quoting, and data import terms, defined in plain language.
What Is the Critical Chain in Manufacturing Scheduling?
The critical chain is the longest dependent path through a plan once shared machine contention is counted, not just step precedence. Here is how it differs from the critical path.
What Does Finite Capacity Mean in EDGEBIC?
Finite capacity means the scheduler refuses to book more hours on a machine than that machine actually has. See exactly how EDGEBIC enforces it, day by day and shift by shift.