Reading a Red Day on the EDGEBIC Capacity View

A red cell on the EDGEBIC by User Solutions capacity view means one thing precisely: assigned hours divided by that day's capacity is above 100%, so more work is booked on that station for that date than the day physically holds. The color is not an opinion, and the size of the overload is a number you can read. This deep dive covers where both halves of that fraction come from, how to find out which jobs caused it, and the four-step playbook that turns a red cell into a decision in a few minutes.

The tab that shows it is covered in the dashboard overview, and the mechanics of the resource calendar and the override dialog are in the dashboard setup guide.

What the Red Actually Computes

Every cell on the 14-day planner heatmap is one work center on one date:

percent loaded = assigned hours / total capacity x 100
oversold       = percent loaded > 100

Assigned hours are summed from the allocations the scheduler booked on that work center for that date. Not the routing estimate, not the job total: the hours the plan actually put on that machine on that day.

Total capacity comes from the capacity calculation service, which is the same source the reports use, so the dashboard and the Work Center Utilization report agree by construction. Capacity is shift hours less holidays and downtime, multiplied by instances and by the utilization percentage, and superseded entirely by a per-day override when one exists for that date.

That shared source matters. When a planner and a supervisor argue about a station's load, they are almost never disagreeing about capacity arithmetic. They are looking at different windows.

Worked Example: Three Stations, Three Days

Take Monday to Wednesday across three work centers. Capacity, from the shift calendars:

Assigned hours, from the scheduling run:

Which gives:

Two readings worth pulling out. MILL-1 on Tuesday and LATHE-2 on Monday are both at exactly 100%, which is full but legal: every hour is spoken for and there is no slack for a delay. HEAT-1 on Tuesday is at 108.3%, which is two hours of work with nowhere to go, on the station flagged as the constraint. The bottleneck panel summarizes the same picture as today's load and a seven-day average, which here is 97.2%: a constraint running at effectively full capacity all week, where any disruption becomes lateness immediately.

The Utilization Bands, and What They Are Not

The Work Center Utilization report grades the same relationship over a range rather than a day:

CRITICAL does not mean physically impossible. It means the scheduled hours exceed the capacity the system believes exists, and the most common reason for that is a configuration gap rather than a real overload. A work center set to one instance while three identical machines sit on the floor will read triple its true load, permanently. Before treating any CRITICAL row as a capacity crisis, confirm the instance count, the shift assignments, and whether an override is in play. The full list of causes lives in work center overload causes and fixes.

One more legitimate case: synchronized parallel operations deliberately mirror the same work across multiple machines, which can push a station past 100% by design. Knowing whether your routings use that pattern saves an investigation.

The Playbook: Four Steps From Red to Decided

1. Identify the day and the station

Hover the heatmap cell and read the raw numbers: assigned against total, and the percentage. "108%" is a color. "13 hours booked against 12 hours of capacity" is a decision you can make. Alternatively, open the per-day capacity dialog for the station, whose day grid shows shift default hours, capacity hours, loaded hours, the overridden flag, and a reason, with summary counters for total capacity, loaded, free, over capacity, and overridden days.

2. Find out who is causing it

Open the resource calendar, set the mode and period to match, and click that station's hours-assigned cell. The job detail popup lists every allocation behind the number: job number, product, work center, shift, date, instance, transaction hours, and pieces. Those rows sum back to the cell value under whatever shift and job filters are applied, which is also the usual explanation when they seem not to.

The same answer is available from the Work Center Utilization report's per-work-center tab: select the station's row and the job backlog drill-down fills underneath it.

At this point you know the day, the size of the gap, and the names of the jobs competing for the station. Everything before this step is diagnosis; everything after is choice.

3. Pick the cheapest fix

The discipline that keeps this honest: fix capacity where capacity is wrong, and move work where load is wrong. The override exists to record calendar truth, not to make a red cell green. A station whose capacity gets edited upward every week is not a scheduling problem being solved; it is a capacity investment being deferred.

4. Re-run and verify

Nothing moves by itself. Adding four hours to Tuesday changes what capacity exists; re-running Drive Schedule is what plans against it. Then re-check the heatmap. The cell should clear, and the job status donut should show any job that was structurally late move to a healthier slice.

Worked impact

Tuesday shows a station red at 108%: 13 hours booked against 12 hours of capacity. Overtime is approved, so you double-click its bar, type 16 into the capacity column for that date, and add a reason. The dialog's over-capacity counter drops to zero and the dashboard refreshes when the dialog closes. The jobs stay exactly where they are. You re-run Drive Schedule, the plan rebuilds against 16 hours, and the cell clears. Total elapsed time: under five minutes, with an audit trail naming who authorised the extra hours and why.

Reading Backlog as the Early Warning

The heatmap tells you about the next fortnight. Backlog tells you about the month after.

In the resource calendar, backlog is the forward sum of remaining hours as of each period, so it burns down as work is consumed: a 24-hour step spread over three days reads 24, then 16, then 8, then 0, rather than repeating 24 until it finishes. Read the trend rather than the level. A station whose backlog reads 152, then 118, then 96 across three weeks is clearing its queue, slowly. A station whose backlog rises week on week is receiving work faster than it clears it, and that is a lateness forecast weeks before anything turns red.

That is classic input and output control, and it is the metric to watch if you only have time for one. Our capacity utilization KPI guide covers the generic measure, and department capacity analysis shows the roll-up when the question is about a whole area rather than one machine.

When the Views Seem to Disagree

Two apparent contradictions come up regularly, and both are honest.

Heatmap red, utilization report GOOD. The heatmap is per day; the report averages a range. One oversold Tuesday inside a comfortable month is genuinely both. Use the per-day dialog for day-level truth and the report for the trend.

Dashboard tile calm, floor busy. The cockpit does not auto-refresh: each tab loads when you switch to it, and Refresh now reloads on demand. Click it when the meeting starts. The rest of the traps in this territory are collected in dashboard misreading mistakes, and the report-side equivalents in report reading mistakes.

The Point of the Color

A red day is not a failure of the schedule. It is the schedule refusing to pretend, which is the entire premise of finite capacity: an infinite-capacity plan would have accepted those 26 hours into a 24-hour day and let the floor discover the problem on Tuesday morning. Named, sized, and attributed to specific jobs on the previous Thursday, the same overload is a five-minute decision.

For the full system behind these numbers see the complete EDGEBIC guide, and for what shops recover once red days get resolved early rather than late, the documented results. Ready to see your own load painted honestly? Bring your orders and calendars to a demo.