Critical Ratio Scheduling Explained

Critical ratio scheduling ranks every open job by one number: the time remaining until its due date divided by the work remaining to finish it. A ratio below 1.0 means a job is falling behind and should claim a machine sooner; a ratio of exactly 1.0 means it is on pace; a ratio above 1.0 means it has slack to spare. The strength of the rule is that it weighs both halves of the risk at once, the deadline and the workload, instead of looking at only the calendar. EDGEBIC by User Solutions treats critical ratio as one of the dispatch orderings its optimizer evaluates, which lets you test a pace-aware sequence against your standard plan without committing to it blindly.

The formula, in planner terms

Critical ratio is deliberately simple. You divide two quantities measured in the same units, usually working days:

Critical ratio = time remaining until due date  /  work remaining

Time remaining is the number of working days between now and the due date. Work remaining is the number of working days of processing still left in the routing, summed across every operation that has not yet finished. Read the result like a fuel gauge:

• Below 1.0: less calendar time left than work left. The job is behind pace and at risk of being late.
• Exactly 1.0: calendar time and work are matched. No margin, no deficit.
• Above 1.0: more calendar time than work. The job has slack.

The lowest ratio is the most urgent, so a critical-ratio queue runs the smallest numbers first. Unlike a fixed priority integer, the ratio changes on its own as days pass and as operators log completed hours against the routing. A job that looked safe on Monday can slide under 1.0 by Wednesday if an upstream step ran long, and the rule surfaces that automatically.

Why the calendar alone misleads you

The reason critical ratio exists is that a due date on its own hides half the picture. Two jobs due the same Friday are not equally urgent if one is nearly finished and the other has barely started. A pure earliest due date sort calls them a tie and picks arbitrarily. Critical ratio does the arithmetic that a planner does in their head: how much runway is left, and how much runway does the work actually need?

This matters most in a finite capacity plan, where contested machine time is the whole game. When a machine can take only one job at a time, the sequence decides who is late. Putting the nearly-finished job ahead of the barely-started one wastes the scarce slot on a job that had margin, and starves the job that did not. Critical ratio spends the machine on the job with the least room to spare.

A worked example

Take three jobs competing for the same milling machine on a Monday morning. Friday is 4 working days out.

A critical-ratio sequence runs MO-202 first (0.67), then MO-203 (1.40), then MO-201 (2.00). Notice what a plain due-date sort would have done: it would run MO-201 and MO-202 in some tied order before MO-203, and it would happily put MO-201 (which has plenty of margin) ahead of MO-202 (which is the only job actually behind pace). Critical ratio corrects that. It pulls the one endangered job to the front and lets the two comfortable jobs wait.

Now let the clock advance. Say MO-202 runs Monday and Tuesday and its work remaining drops to 2.0 days, while nothing else moves. On Wednesday, with 2 working days left to Friday, MO-202's ratio becomes 2 divided by 2, which is 1.0: back on pace. The number reset itself because both inputs changed. That self-correcting behavior is the entire appeal of the rule.

How critical ratio fits the EDGEBIC engine

The standard engine does not sort by critical ratio as its default. It sorts every order deterministically by priority, then start date, then due date, so the same inputs always produce the same sequence and any change traces back to a data change. That determinism is a feature, and it is described in how a scheduler decides which job runs first.

Critical ratio enters through the optimizer. The multi-run search re-runs the unmodified engine under several complete global orderings, including an earliest-due-date ordering, shortest and longest processing time, seeded shuffles, and a critical-ratio ordering. It scores every resulting schedule and proposes the single best one. That proposal is clamped never worse than the baseline, and nothing changes until you accept it. So instead of betting the whole plant on one dispatch rule, you let the optimizer test critical ratio as one candidate among many and keep it only if it genuinely helps. The mechanics live in the optimizer guide.

There is also a manual path. Because critical ratio is just time remaining over work remaining, you can compute it from the same fields you already maintain (the due date and the routing hours) and use it to inform how you set the priority integer or the start date. The engine then honors your ordering directly.

When critical ratio is the right tool, and when it is not

Critical ratio shines when due dates and work content vary widely across the queue, which is the normal state of a job shop. It keeps attention on the job closest to trouble and adapts as the day unfolds.

It is a weaker choice in a few situations. On a heavily setup-dependent line, running strictly by critical ratio can scatter similar jobs and pile up changeover time, which is why the optimizer also weighs a setup-minimizing sequence; that trade-off is covered in how a scheduler trades off setup against due date. Critical ratio also assumes your work-remaining estimate is honest: if routing hours are wrong, the ratio is wrong, and the rule confidently prioritizes the wrong job. Clean routing data is the price of admission.

Used well, critical ratio turns a static priority list into a pace-aware one. It answers the question a planner actually cares about, not "which job is due soonest" but "which job is most likely to be late," and it keeps answering it as the shift moves. See how a pace-aware sequence would reshape your own queue in EDGEBIC, and read the full sequencing pipeline in the scheduling engine guide.