- Home
- Blog
- Glossary (EDGEBIC)
- What Is a Blocker Hint on a Late Job?
A blocker hint is a one-line diagnosis shown against each row of the Late Jobs report, derived from the job's progress and how late it is, that tells you which kind of lateness you are dealing with. It is triage, not root cause: it points at the right question so you do not start by reading the wrong part of the record.
This entry defines the blocker hint and shows how it reads inside EDGEBIC by User Solutions. For the wider index of terms, see the manufacturing glossary; for the report it appears on, see EDGEBIC reports explained; and for the figure it sits beside, see what is days late on a job.
How It Works
The Late Jobs report lists every scheduled job whose planned end runs past its due date, ranked worst first. Each row carries the due date, the scheduled end, the days late, the percent complete, and a status. Those columns tell you the size of the problem. They do not tell you what kind of problem it is.
The blocker hint fills that gap by combining two numbers already on the row into a phrase.
If percent complete is essentially zero, the hint says there are no actuals and the job never started. This is a completely different situation from a job that is being worked and running behind, and it usually means the job was not released, not picked up, or blocked before anyone touched it.
If percent complete is below half and the job is more than five days late, the hint says the job is significantly behind plan. Work has begun, but the gap between where it is and where it should be is wide enough that finishing on the current trajectory is unlikely.
Otherwise the hint says the schedule slipped. This is the catch-all for jobs with meaningful progress that are not dramatically behind, and it usually points at displacement rather than at the job itself.
The thresholds are intentionally coarse. They separate three conversations that call for three different first moves.
A Concrete Example
A supervisor opens the Late Jobs report on Monday morning and finds eleven rows.
Three of them read that there are no actuals and the job never started. All three route through the same station. The supervisor's first move is not to chase production but to ask whether time is being logged at that station at all, because a station whose operators are not recording hours produces jobs that look untouched regardless of how much work has happened. It turns out the station has been logging on paper for a week. Those three rows are a data problem, and once actuals are entered, two of them are not late at all.
Two rows read that the job is significantly behind plan. Both are genuinely in trouble: work started, less than half is done, and the due date passed a week ago. These are the customer calls.
The remaining six read that the schedule slipped. Looking at one of them, the operations are progressing normally and nothing about the job has overrun. What moved was the plan around it: a rush order was inserted ahead of it last week and pushed its window out. The fix belongs in sequencing, not on the floor.
Three hints, three different first moves, from one column.
How EDGEBIC Uses It
In EDGEBIC, the blocker hint is a column on the Late Jobs report, sitting alongside the job, product, customer, due date, scheduled end, days late, percent complete, and status. Rows sort by days late descending, so the worst jobs and their hints are at the top.
The hint is derived only from percent complete and days late. It has no knowledge of downtime, material shortages, operator absence, or anything else that happened physically, so it should never be quoted as the reason a job is late. Its value is that it costs nothing to read and it reliably separates a job that never started from a job that started and fell behind from a job that was displaced.
Percent complete on the report is hours-based, computed from actual hours against planned hours, and it falls back to pieces only when no hours exist. That dependency is worth remembering, because the never-started hint is really a statement about logged hours rather than about physical activity.
Once the hint has pointed you somewhere, the depth is elsewhere. The Job Audit Trail reconstructs one job's whole story including its reschedules and its daily actuals; Work Center Progress breaks a job's percentage down step by step so you can see which operations account for the missing portion. The hint gets you to the right one of those in a glance.
For the classification these jobs come from, see job status buckets on a dashboard. For the column reference built into every report, see what is a column glossary in reporting, and for the window the report runs over, see what is a reporting window.
A blocker hint is a short plain-language diagnosis shown against each row of the Late Jobs report, telling you what kind of lateness you are looking at so you know where to dig first. It is derived from two figures already on the row, the percent complete and the number of days late, and it resolves to one of three phrasings. It is triage rather than root cause: it points at the right question to ask, and the answer still comes from looking at the job.
When percent complete is essentially zero, the hint reads that there are no actuals and the job never started. When percent complete is under half and the job is more than five days late, the hint reads that the job is significantly behind plan. Otherwise the hint reads that the schedule slipped. The thresholds are deliberately coarse, because the purpose is to separate three different conversations rather than to measure anything precisely.
No, and treating it as one will mislead you. The hint is computed only from progress and lateness, so it has no knowledge of machine breakdowns, missing material, absent operators, or anything else that happened on the floor. It tells you which class of problem you are probably in so you can start in the right place. The real reason comes from the job's own history: its operations, its actuals, and its reschedule trail.
Often they are not blocked at all, and the more likely explanation is that actuals are not being logged for that area. The hint is computed from percent complete, and percent complete comes from logged hours, so a station whose operators are not recording time produces jobs that look untouched no matter how much work has actually been done. Before chasing production, check whether any actuals exist for the work centers those jobs route through in the same period. If the answer is none at all, you have a data-capture problem rather than a production problem, and fixing the logging habit will clear most of the rows at once. If actuals do exist elsewhere but not on these jobs, then the hint is telling you something real and the jobs genuinely have not been picked up.
That hint is the catch-all, so it is what you get when a job is late without being one of the two clearer cases: it has meaningful progress and it is not dramatically behind. In practice this usually means the job is being worked but the plan around it moved, most often because other work was inserted ahead of it and pushed its window out, or because upstream operations ran longer than planned and the whole chain shifted. The place to look is the job's reschedule history and its operation-level progress, which will show whether the job's own steps overran or whether its dates were displaced by something else. Those two causes need different responses, and the hint cannot tell them apart on its own.
Expert Q&A: Deep Dive
Q: A whole cluster of jobs shows no actuals and never started. Are they really all blocked?
A: Often they are not blocked at all, and the more likely explanation is that actuals are not being logged for that area. The hint is computed from percent complete, and percent complete comes from logged hours, so a station whose operators are not recording time produces jobs that look untouched no matter how much work has actually been done. Before chasing production, check whether any actuals exist for the work centers those jobs route through in the same period. If the answer is none at all, you have a data-capture problem rather than a production problem, and fixing the logging habit will clear most of the rows at once. If actuals do exist elsewhere but not on these jobs, then the hint is telling you something real and the jobs genuinely have not been picked up.
Q: The hint says the schedule slipped, but nothing about the job has changed. What does that mean?
A: That hint is the catch-all, so it is what you get when a job is late without being one of the two clearer cases: it has meaningful progress and it is not dramatically behind. In practice this usually means the job is being worked but the plan around it moved, most often because other work was inserted ahead of it and pushed its window out, or because upstream operations ran longer than planned and the whole chain shifted. The place to look is the job's reschedule history and its operation-level progress, which will show whether the job's own steps overran or whether its dates were displaced by something else. Those two causes need different responses, and the hint cannot tell them apart on its own.
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
The EDGEBIC Scheduling Glossary Index
A themed index to the EDGEBIC glossary: scheduling engine, capacity and calendars, materials and planning, shop floor, reporting, quoting, and data import terms, defined in plain language.
What Is the Critical Chain in Manufacturing Scheduling?
The critical chain is the longest dependent path through a plan once shared machine contention is counted, not just step precedence. Here is how it differs from the critical path.
What Does Finite Capacity Mean in EDGEBIC?
Finite capacity means the scheduler refuses to book more hours on a machine than that machine actually has. See exactly how EDGEBIC enforces it, day by day and shift by shift.
