- Home
- Blog
- Troubleshooting
- A Daily Capacity Override Was Ignored: Causes and…
A Daily Capacity Override Was Ignored: Causes and Fixes
When a daily capacity override does not change the schedule, the cause is almost always one of three things: the scheduling run was built before you saved the override, the override sits on a day the shift does not run, or it is on a different shift than the job is using. EDGEBIC by User Solutions resolves the available hours for every work center, shift, and date through one capacity chain, and a daily override is the highest-priority entry in that chain, so a genuine override that the job could reach is never quietly overruled.
The controls you use to diagnose this are the Per-Day Capacity Override popup, the Resource Calendar, and a fresh scheduling run. This post is the detailed version of the ignored-override symptom in the EDGEBIC troubleshooting guide. For the range-level version, a monthly capacity override did not apply as expected covers date-range budgets, and finite versus infinite capacity scheduling covers why capacity limits drive the whole plan.
What You Are Seeing
You set an override on a cell, the Resource Calendar shows the new hours, but the last schedule still placed work as if the old capacity applied: a job did not fill the extra Saturday hours you authorized, or it kept spilling past a reduced-capacity day you tried to cap.
Why It Happens
Cause 1: The Run Was Built Before You Saved the Override
The scheduling engine reads all capacity overrides once, when a run starts. If you save an override after that run has begun, the running plan never sees it. The dashboard updates immediately because it reads capacity live, so the two surfaces can disagree until the next run.
How to tell: the Resource Calendar shows the new hours, but the plan on screen predates your edit.
Cause 2: The Override Is on a Day the Shift Does Not Run
A daily override only adds hours to a day the shift already works. If the shift has no working pattern for that day, for example a Saturday when weekend production is off, the override is a no-op. Entering zero hours on such a day changes nothing either.
How to tell: the day is one the work center normally shows as closed, and the override did nothing to open it.
Cause 3: The Override Is on the Wrong Shift
An override is scoped to one work center, one shift, and one date. If the job runs on the day shift and you overrode the night shift, the override is real but the job never touches it.
How to tell: the override cell and the job's actual shift do not match.
A Related Case: the Number Is Wrong, Not Ignored
If the override applied but the hours look off, remember the override is used verbatim: the engine does not multiply it by instances or utilization. Entering the per-instance figure on a multi-instance machine gives a fraction of the intended capacity.
How to Fix It
- For a stale run: re-run scheduling. The engine reloads overrides at run start, so the next run picks up your edit and the plan and dashboard agree.
- For a non-working day: turn on weekend production for the work center, or use a monthly capacity override to create schedulable slots across the range. A daily override cannot open a closed day by itself, and if a range override you already entered did nothing, a monthly capacity override that was ignored walks the chain that outranks it.
- For the wrong shift: enter the override on the shift the job actually uses, then re-run.
- For a wrong number: re-enter the override as the total effective hours you want that day, not the per-instance figure.
How to Diagnose It, in Order
- Confirm the day is one the shift runs, or that a monthly override or weekend production has opened it.
- Confirm the override is on the shift the job uses, not a sibling shift.
- Re-run scheduling, because the engine reads overrides only at run start.
- Compare the number against your intent: the override is verbatim, never re-multiplied by instances or utilization.
- Check the Resource Calendar to confirm the override is stored, which rules out a save that did not commit.
How to Prevent It
- Re-run scheduling after any capacity edit before you judge the plan against it. The dashboard is instant; the plan is only as fresh as its last run.
- Open closed days with the right tool. Weekend production or a monthly override makes a day schedulable; a daily override only adjusts a day the shift already works.
- Enter the total effective hours, not per-instance hours, since the override is used exactly as typed.
- Match the override to the shift the work runs on, because an override on an idle shift is invisible to the job. If a whole work center shows zero on a day you expected capacity, capacity shows zero for a work center walks the date gate.
The most common reason is timing: the scheduling engine loads capacity overrides once when a run starts, so an override you enter after the run began is not seen until you run scheduling again. The dashboard shows the new number immediately, but the last schedule was built against the old capacity. Two other causes are an override entered on a day the shift does not run, which is a no-op, and an override placed on a different shift than the one the job is using.
Not on its own. A daily capacity override only operates on days the shift already runs, so entering hours on a day the shift has no working pattern, such as a weekend when weekend production is off, does nothing. To open a non-working day, either turn on weekend production for the work center or use a monthly capacity override, which creates schedulable slots across the range it covers. A zero-hour daily override on a non-working Saturday is effectively nothing.
No. A daily capacity override is the final effective number, used verbatim. The engine does not multiply it by the number of machine instances or by the utilization percentage. If a work center has three instances and you want a total of twelve hours available, enter twelve, not four. Entering the per-instance figure gives you one-third of the capacity you intended and is a common reason an override looks wrong rather than ignored.
Expert Q&A: Deep Dive
Q: I approved a four-hour Saturday overtime run, saved the override, and the job still did not land on Saturday. What did I miss?
A: Check two things in order. First, confirm the work center actually runs a shift that day or that you used a monthly override to open it: a daily override only adds hours to a day the shift already works, so on a plain non-working Saturday it is a no-op and you need weekend production on or a monthly override instead. Second, if the day is genuinely schedulable, re-run scheduling: the engine reads overrides at run start, so an override saved after the last run is only picked up on the next one.
Q: The dashboard shows my override but the schedule clearly used the old capacity. Which one is right?
A: Both are right for different moments. The dashboard reads capacity live, so it reflects the override the instant you save it. The schedule was built from the snapshot the engine took when that run started, so if you changed the override after the run, the plan still carries the old number. Re-run scheduling and the two agree. This is why a capacity edit should be followed by a fresh scheduling run before you trust the plan against it.
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
An Operation Moved and the Machine Was Free: Finding the Hidden Cause
A job slid and every machine shows open hours. Tooling is the cause the Gantt cannot draw. How to rule it in or out in two minutes before you chase calendars.
An Operation Shows Running Forever Though All Hours Are Logged
A step stays in progress after every hour is logged because completion is an explicit stamp, not an hours threshold. How to close it and stop it recurring.
Another User Changed This Record: Causes and Fixes
EDGEBIC refuses a save when the record moved after you loaded it. The usual cause is a colleague, but the message also appears when you are alone. How to read it and what to do.
