Every factory has a version of this story.
The maintenance team schedules a four-hour line shutdown for a Saturday. The planning team knows. The shift supervisor knows. The production schedule accounts for it. And yet, when Monday rolls around, and someone pulls the OEE report, that four-hour window shows up as unplanned downtime because no one got around to manually labeling it in the system after the fact.
It’s not a failure of discipline. It’s a failure of design. When your tools require operators to retroactively categorize events that were already on the calendar, you’ve created unnecessary work and introduced unnecessary error into your most important production data.
Arch’s new Planned Downtime Scheduling feature is designed to close that gap without adding process.
The Problem With Manual Labeling of Planned Events
In most manufacturing environments, downtime gets categorized through a mix of real-time labeling by line operators and after-the-fact review by supervisors or engineers. That process works reasonably well for unplanned stoppages, where the cause genuinely needs to be investigated and categorized.
But planned downtime is different. You already know why the line stopped. You scheduled it. The information exists. It’s just sitting in a spreadsheet, a planning system, or someone’s head, completely disconnected from your production monitoring platform.
The downstream consequences are significant. When planned stops don’t get labeled properly, they drag down your OEE numbers in ways that obscure true performance. Maintenance efficiency looks worse than it is. Shift productivity reports are misleading. And when leadership asks why availability is down, someone has to dig through the data and explain that half of it was planned, which should have been obvious from the start.
What Planned Downtime Scheduling Does
Planned Downtime Scheduling introduces a dedicated Planning tab inside ArchFX React, where administrators can create and manage scheduled downtime events at the site, area, or line level.
One of the most practical aspects of the feature is how it handles scale. A single planned downtime event configured at the site level automatically applies to every line within that site: no need for someone to manually replicate it line by line. For a facility running ten or twenty lines, that’s the difference between one entry and twenty. A planner can also load an entire week’s worth of scheduled events in a single CSV import, making it practical to stay ahead of the schedule rather than scrambling to catch up after the fact.
Recurring events are equally powerful. Meal breaks, shift-change windows, and weekly PM slots only need to be configured once. The system repeats them on the defined cadence indefinitely, or until the recurrence end date. For one-off events like a facility upgrade or a planned shutdown, the same interface handles non-recurring entries just as cleanly.
Whatever the case, you define it once (give it a name, a time range, a scope, and an event type), and the system takes it from there.
When machine data shows an actual downtime occurring during a scheduled window, Arch’s AI-powered auto-labeling engine does three things automatically:
It splits the downtime. If the actual stoppage doesn’t align perfectly with the planned window (say, the machine stopped five minutes early or ran ten minutes over), the system splits the event at the boundary. The portion that overlaps with the planned window gets labeled with the planned reason. The remainder stays separate for manual review.
It applies the right label. The system maps the scheduled event to the most relevant downtime reason and category based on the event name and description.
It respects priority. When multiple planned events overlap (a break window falling within a larger no-production period, for example), the system applies a clear priority order: No Production takes precedence over Breaks, which in turn take precedence over general Time Slots. The logic is consistent and auditable.
Built for How Real Factories Operate
The feature is designed around scope, not just individual lines. A single planned downtime record can apply to an entire site, a specific area, or individual lines, and can include or exclude specific lines as needed. That flexibility matters in practice: if the entire site is offline for Christmas, one entry covers every line. If Building 1 is running a training session and going offline while the rest of the facility runs normally, you scope it to that building alone. No copying or duplicating configuration across entities.
For facilities that run complex schedules, bulk CSV import handles non-recurring events at scale. Full export and mass delete are available in the table view. And because past planned downtimes represent committed historical data, they’re locked once they’ve occurred: even admins can’t edit or delete them after the fact, protecting the integrity of your records.
The calendar and table views give planners a clear picture of what’s scheduled and when, with full visibility into recurring patterns. Access is role-controlled: only Admins can create or modify planned downtime events. But everyone has visibility.
What Changes on the Floor
For operators, the impact is immediate and, in the best way, invisible. Planned stops simply appear in the system, already labeled, without requiring any action from the people running the line. That means less time on the downtime form, fewer missed labels, and more attention where it belongs: on production.
For supervisors and engineers reviewing shift data, the noise drops significantly. Planned events are clearly distinguished from genuine unplanned stoppages, so anomalies stand out instead of getting buried. When something unexpected does happen during a scheduled maintenance window (say, a secondary failure that extends the downtime), the split logic surfaces that clearly rather than rolling it into the planned bucket.
For operations leadership pulling weekly and monthly reports, OEE numbers start to reflect actual performance rather than a mix of planned and unplanned that has to be mentally adjusted by anyone who knows the context.
The Bigger Picture: AI That Works With Your Plan
What makes this feature different from a simple scheduling tool is that the intelligence works in both directions. Arch doesn’t just record what you planned; it actively reconciles your plan with what actually happened on the floor in real time and classifies accordingly.
That’s the core value of Arch AI applied to downtime management: not replacing human judgment, but handling the mechanical work of categorization so human attention can focus on the stops that actually need it. When every planned shutdown is automatically captured and labeled, your team’s review time shifts toward investigating genuine problems: the unplanned events that carry a real signal about equipment health, process stability, and operator needs.
Scheduling of Planned Downtimes is now available on the Arch platform.
Case Study
Articles 
