Several Anomaly Checks Fired on One Job: Which One to Fix First

When one job trips several anomaly checks at once, most of the rows are usually symptoms of a single root cause, and the way to find it is to sort by severity and work the critical rows top down. EDGEBIC by User Solutions runs its checks independently, so a single scheduling problem can light up four chips at the same time. Fixing them in display order wastes passes, because several of them will clear on their own once the cause is corrected.

This post covers the documented pairings that share a root cause, the order to work them in, and the combinations that are genuinely unrelated. It is the triage entry in the EDGEBIC troubleshooting guide. For the report itself see how to run the scheduler anomalies report, and for the definition of a check see what is a scheduling anomaly check.

What You Are Seeing

You filter the anomaly report to one job and the chip strip lights up in several places at once: an over-utilization row, an instance collision, an hours mismatch, and a consistency drift row, all naming the same work center and often the same date. Nothing in the display says which one came first.

Why It Happens

The checks are deliberately independent. Each one asks a narrow question about the stored schedule and reports what it sees, without knowing what the others found. That independence is what makes the report trustworthy, and it is also why one defect produces a cluster of rows rather than a single verdict.

A machine unit that ends up carrying two jobs at the same time, for example, is simultaneously a collision, an over-utilization, and, once the hours are summed, a consistency problem. Three checks, one defect.

The Pairings That Share a Root Cause

Each row in that table is a documented cascade. In every case the second and third findings are consequences: correct the first and re-run, and they stop reporting.

How to Fix It

• Sort by severity first. Critical before warning, every time. The critical rows are the ones that describe a defect rather than an observation.
• Match the cluster against the pairings above. If it matches, you already know the root cause and can skip the exploration.
• Fix one thing, then re-run scheduling. Do not fix four things in one pass, because you will not learn which fix mattered.
• Re-open the report after the run. The report reads current stored state at load time, so a pane left open across a run shows the old picture.
• Read what survives. Rows that persist after a clean re-run were never part of the cascade.

How to Diagnose It, in Order

1. Filter to the job so the schedule-shaped checks report on it alone.
2. Sort by severity, then by check identifier, so related rows group together.
3. Read the detail column on the critical rows. It carries the concrete values: booked hours against the cap, the two jobs in a collision, the drift in minutes.
4. Name one root cause using the pairings table or the description itself.
5. Fix it, re-run scheduling, re-open the report, and compare the row count.
6. Repeat for whatever is left, and stop when only acceptable warnings remain.

The Combinations That Are Not Related

Not every cluster has a single cause. A booking on a holiday and an ambiguous overlap configuration can appear on the same job and share nothing: one is a calendar entered after the run, the other is a routing setting. Treat the pairings table as a set of known shortcuts rather than a rule that every cluster collapses.

The reliable test is the re-run. Whatever disappears was part of a cascade. Whatever stays was always separate.

How to Prevent It

• Clear critical rows before you publish a plan, which is the discipline described in clearing scheduler anomalies before publishing.
• Watch for a check that reappears on different jobs. That pattern points at shared configuration, usually a work center or a routing, rather than at any one job.
• Get the instance count right on every machine, because an understated count turns normal loading into an over-utilization report and drags other checks along with it. See a work center shows more hours than it has.
• Do not treat warnings as a queue to empty. Idle gaps and hours differences often describe reality, and chasing them hides the critical rows that matter.