Nine Shift and Calendar Setup Mistakes That Quietly Break a Schedule

Shift and calendar mistakes almost never throw an error: they produce a plan that is internally consistent and quietly disconnected from the plant, because the scheduler believes the calendar literally and has no way to know it is wrong. The nine below account for most of the calendar problems that reach a support conversation, each with the symptom you would actually notice first.

EDGEBIC by User Solutions will tell you when a work center has no shift at all. It cannot tell you that the shift you defined is optimistic, or that a recurring holiday is set to the wrong Monday. This article covers the quiet class. For the layers themselves, start with shifts and calendars explained and the setup guide.

1. Changing the Calendar and Not Rerunning the Schedule

The mistake. Adding a holiday, extending a shift, or entering an override, then reading the Gantt and concluding nothing happened.

Why it is wrong. Saving calendar data never reschedules. The plan on screen was computed against the old calendar and keeps every date, including allocations that now sit outside working hours.

The symptom. "I added the holiday and jobs are still scheduled on it." Also its more expensive cousin: promising dates from a plan that predates the change.

The fix. Run Drive Schedule and review the result before communicating anything. Completed work is never moved by a reschedule, which is the guarantee that makes frequent reruns practical. The pipeline is described in the scheduling engine guide.

This one is first because it masquerades as every other mistake on the list. Confirm the plan is current before diagnosing anything else.

2. A Recurring Holiday on the Wrong Month or Day

The mistake. A recurring holiday saved with a date that is off by a day, or in the wrong month entirely.

Why it is wrong. Only the month and day of a recurring record are used. The year is ignored, and the pattern expands into every year the scheduler plans across.

The symptom. The plant works through the real holiday and shuts down on a normal Tuesday. In the grid, the record looks perfectly valid.

The fix. Open the holiday, correct the date, rerun. Then put a five-minute annual review of the recurring list on the calendar, because a wrong record repeats itself indefinitely and nothing surfaces it.

3. Shrinking a Shift to Absorb Occasional Losses

The mistake. The plant loses 45 minutes to a monthly meeting, so somebody shortens the day shift by 45 minutes.

Why it is wrong. The shift is the weekly working pattern. Shortening it charges the time every single day, on every work center that inherits it, and records no reason.

The symptom. Capacity that is quietly 6% low across the plant forever, and a shift whose hours nobody can justify a year later.

The fix. Model it as a partial plant holiday for the meeting window. Each shift is charged only its own overlap:

One record, correct per shift, self-documenting. One caveat on repetition: the Recurring each year flag matches the same month and day annually, so it carries a fixed-date holiday but not a monthly meeting. A monthly all-hands is twelve records a year, and if that is too tedious to sustain, netting the average into the shift is the honest alternative. Reserve shift edits for genuine changes to the working pattern.

4. Per-Machine Hours in a Capacity Override

The mistake. A three-instance work center has a PM window where each machine loses half a shift. The planner types the per-machine figure into Capacity (h).

Why it is wrong. An override states the effective total for the day across every machine, and the engine uses it exactly as typed. It never multiplies an override by the instance count.

The symptom. The day offers a third of the intended hours. The Resource Calendar bar looks far too short and work quietly pushes into following days.

The fix. Always enter machines times hours: three instances at four hours each is 12. Related trap on the other side, a zero-hour override on a day the shift does not run is a no-op, because an override adjusts an existing slot rather than creating one. The mechanics are in how EDGEBIC resolves capacity day by day.

5. Overriding One Shift and Expecting the Whole Day

The mistake. A work center runs day and night. The planner overrides Saturday on the day shift and expects a full day of weekend capacity.

Why it is wrong. Overrides are keyed to work center, shift, and date. Each shift is a separate cell.

The symptom. Exactly half the expected capacity. A job that runs Saturday morning and then stops.

The fix. Override each shift you intend to run, and check the Shift: selector before typing rather than after. The same trap applies to closures: zeroing a machine's day shift leaves its night shift fully schedulable.

6. A Stale Custom Work Center Calendar

The mistake. One work center was given its own shifts for a good reason a year ago. The plant pattern then changed and nobody revisited the exception.

Why it is wrong. A work center with Use Global Shifts unticked follows only its own shift list. Global edits do not reach it, by design, and the amber Custom badge in the Shift Calendar column is the only indication.

The symptom. A plant-wide shift extension improves every date except one department's. Or one machine's bars sit in the wrong part of the day.

The fix. Edit that work center's own Associated Shifts tab, or re-tick Use Global Shifts to rejoin the plant calendar. As a standing rule, prefer global shifts and keep custom calendars for genuine exceptions only. The work center side is covered in work center configuration mistakes.

7. Expecting Weekend Hours to Produce Weekend Work

The mistake. Saturday hours added to the shift, and no jobs appear on Saturdays.

Why it is wrong. Weekend production is off by default at the work center level, and the date gate runs before capacity is ever calculated. A Saturday can carry shift hours and still be skipped.

The symptom. Configuration that looks right, and a weekend that stays empty.

The fix. Use a per-day capacity override on the specific Saturdays you actually intend to run, entered per shift, with a reason. That is not a workaround: it is the better model, because occasional overtime should be a deliberate decision with an audit trail rather than a permanent calendar assumption. For a stretch of weekend work it is one override per Saturday per shift, since the date-range override that would cover the span in one record has no entry point in the current release.

8. Retiring a Shift Without Cleaning Up Its Work Centers

The mistake. A temporary overtime shift is deactivated when the overtime period ends, and nobody revisits the work centers that were assigned to it.

Why it is wrong. Schedules already generated keep their dates, so nothing looks broken. The next scheduling run simply has no capacity from that shift, and the work centers still carry the association without the hours.

The symptom. A capacity drop on specific machines that nobody can trace to a change, because the change was made somewhere else and weeks earlier.

The fix. Before retiring a shift, check which work centers use it. After retiring it, clean up their shift lists so the configuration says what is actually true. Deleting a shift outright has the same effect on future runs, so the same check applies.

9. Looking for a Downtime Screen That Is Not There

The mistake. Maintenance is agreed, someone goes to enter it, finds no downtime editor and no way to say "every Wednesday", and the window never reaches the calendar at all.

Why it is wrong. The scheduling engine understands downtime, including windows that recur on a weekday, but the current release provides no screen for creating those records. A planner who stops at the missing screen leaves the hour in the plan, and the engine keeps offering time the machine was never going to work.

The symptom. The quietest failure on this list: nothing errors, nothing looks unusual, and the machine is simply over-promised by the same hour every week until someone compares the plan to the maintenance sheet.

The fix. Route the loss to one of the two places that do exist.

Two related traps sit underneath. A window that spans two shifts has to be split, because an override lands on one shift only, so a five-hour block across a four-hour shift and its neighbor is two entries and not one. And if a shift goes to zero unexpectedly, check for a stale override before anything else: nothing expires one. The full ordered walk is in how EDGEBIC resolves capacity day by day.

Two Habits That Prevent Most of This

Keep the calendar honest rather than optimistic. A resource planned to 100% of the theoretical clock has no recovery room, and the first breakdown propagates through every downstream date. That reasoning is the same one behind buffer management in the Theory of Constraints and APS literature. Express the headroom explicitly (real shift hours, partial plant holidays, per-day overrides) so the number carries a reason. The measurement side of the same idea is in the capacity utilization KPI.

Put exceptions where exceptions belong. One-off days go in overrides. Plant-wide interruptions go in partial holidays. Only genuine changes to the working pattern go in the shift. Follow that split and the calendar stays readable by whoever inherits it, which over a few years is worth more than any single setting.

The Non-Mistake Worth Knowing

Overnight shift work appears on the calendar day the shift starts. A slice running 22:00 Tuesday to 06:00 Wednesday belongs to Tuesday's allocation. This is consistent everywhere (Gantt, allocation records, capacity screens) and reconciles perfectly once you read overnight rows against their start day. It gets reported as a bug regularly. It is not one.

Next

Fix the calendar, then confirm the arithmetic in how EDGEBIC resolves capacity day by day. If one machine has gone completely quiet, the zero-capacity checklist walks the causes in order. If a job has landed on a closure date, a job scheduled on a holiday covers which layer usually misfired. Bring your current shift and holiday list to a demo and we will read it with you.