What Are Job Status Buckets on a Dashboard?

Job status buckets are the four mutually exclusive slices every active job is classified into for at-a-glance reading: Late, Overdue, On time, and Early. They answer whether a job will hit its promise, which is a different question from whether it has started or finished, and they judge against the delivery-ready date rather than the last machine operation.

This entry defines the buckets and shows how they read inside EDGEBIC by User Solutions. For the wider index of terms, see the manufacturing glossary; for the surface they appear on, see EDGEBIC dashboards explained; and for the workflow states they sit beside, see what is job status in manufacturing scheduling.

How It Works

A job carries a workflow status describing where it stands in its own lifecycle: planned, scheduled, in progress, completed. That does not answer the question a plant manager actually asks, which is whether the promise will be kept.

The buckets answer that. Each job falls into exactly one, assigned by priority so there is never ambiguity about which slice it belongs to.

Late is the worst case and is checked first. A job is late if it finished after its due date, or if it is unfinished and the plan itself lands past the due date. The second half is the important one: lateness is flagged structurally, before the due date arrives, because a plan that already misses the promise is late today regardless of the calendar.

Overdue catches the different failure. Here the plan did meet the due date, but that date has already passed and the job is not done. The plan was fine; execution did not keep up.

On time covers a job whose due date is still open and whose plan lands exactly on it, with no slack, plus any job that actually finished on or before its due date.

Early covers a job whose due date is still open and whose plan lands before it, meaning the plan carries slack.

Progress is deliberately not part of this. Whether a job has physically started appears as a separate badge on the job row, and a started job still lands wherever its dates put it.

A Concrete Example

Four jobs, all due at the end of next week, illustrate the whole scheme.

The first is planned to finish two days before its due date. It has slack, so it is Early. Nothing to do.

The second is planned to finish exactly on the due date. No slack at all, so it is On time, which should be read as a job with no margin for error rather than one that is comfortable.

The third is planned to finish three days past the due date. Nobody is behind on it, nothing has gone wrong on the floor, and the due date has not arrived. It is Late anyway, because the plan itself misses. That is the signal the classification exists to give: you learn about it now, while there is still time to add capacity, split the routing, or call the customer.

The fourth was planned to finish last Wednesday, comfortably inside its due date, and it is still running. The due date has now passed. It is Overdue. The plan was achievable and was not achieved, so the conversation belongs on the floor rather than with the scheduler.

The third and fourth jobs would look identical in a system that only reported whether a due date had passed. Separating them is what makes the buckets actionable.

How EDGEBIC Uses It

In EDGEBIC, the four buckets drive the Job Status donut on the dashboard, with Late in red, Overdue in amber, On time in green, and Early in teal. The active jobs list beneath the donut sorts worst first, so it doubles as an attention queue rather than just a list.

Classification uses the scheduled end plus the product's end-item lead time, which is the date the item is genuinely ready to deliver. That is why job rows display a ready date next to the due date, and it is why the donut agrees with the lateness column on the scheduling grid instead of disagreeing with it. A job whose machines finish early can still be Late if a long lead-time tail pushes delivery readiness past the promise.

The in-progress badge sits on the job row rather than in the donut, keeping progress and promise as separate readings.

The buckets pair naturally with the Late Jobs report, which takes the structural cases and ranks them worst first with a hint about where the problem lies. Reading them together is the usual workflow: the donut tells you how many and how bad, and the report tells you which and why.

For the depth behind a late job, see what is a blocker hint on a late job and what is days late on a job. For the tail that decides the ready date, see end-item lead time, and for the tiles these slices sit among, see what is a KPI tile.