Tool

What does your system turn off first?

Under pressure every system sheds something. The only question is whether the order was chosen by a person or by whichever queue happened to fill first, and contention has no idea which of your capabilities is the safety-critical one.

What the system does, and what it costs

One row per capability that could be turned off on its own. Load is whatever the constrained resource is, in any consistent unit: cores, GPU seconds, bandwidth, requests. The shed trigger is the condition at which it comes off, and a blank one is the finding rather than an omission.

60 % of nominal
The stress case worth planning for: a degraded node, a link at a fraction of its rate, a shared cluster under someone else's load.
CapabilityValueLoad unitsCritical pathShed triggerRemove
7 rows
Critical path means the system is unsafe or non-compliant without it, not merely worse. If more than a third of the rows are marked critical, the word has stopped doing any work.
This calculator runs entirely in your browser. Nothing you type is sent anywhere unless you ask for the result by email at the bottom of the page.
The ladder, in the order things come off
OrderCapabilityValueLoadClassAt 60%Trigger
1Scheduled report generation112udiscretionaryshed80% load
2Historical trend queries222udiscretionaryshedno trigger defined
3Fleet telemetry upload28udiscretionaryshedno trigger defined
heldOperator dashboard live view318udiscretionaryrunning90% load
heldAnomaly detection inference425udiscretionaryrunningno trigger defined
heldClosed-loop setpoint control512ucriticalrunningnever
heldSafety interlock monitoring53ucriticalrunningnever
Least valuable first, and among equally valuable capabilities the heavier one, since shedding it frees more capacity and fewer things have to go. Critical-path rows are held until nothing discretionary is left.
Value retained
77%
Without a ladder: 54%
Unplanned overloads that cut the critical path
67%
The ladder makes this zero until the floor
Capacity floor
15%
Below this the critical path itself does not fit
No shed trigger
3 of 7
These are shed by contention, not by decision
The ladder holds 77% of the value against 54% without one, and it keeps the critical path intact in every case rather than 33% of them.
3 discretionary capabilities have no defined trigger. They will still be shed under load, because something has to be. They will just be shed by whichever queue fills first, at a moment nobody chose, and the first anyone hears of it will be a user noticing the output stopped.
With no ladder, 67% of overloads at this level shed something on the critical path before something discretionary. Contention does not know which is which: the interlock consuming three units and the report consuming twelve are the same kind of work to a scheduler.
Send me this ladder

Your capabilities go with it. If the capacity floor is close to the level you actually run at, the ladder is not the fix and it is worth knowing that before the next incident rather than during it.

Your inputs are included so the reply can be specific.

What a ladder is worth, by how much capacity is left

The reference profile is a plant-floor platform with seven capabilities totalling 100 units of load, of which the two critical-path ones account for fifteen. Planned shedding is compared against contention deciding the order, averaged over two thousand runs at each level.

Capacity leftRungs usedValue kept, plannedValue kept, no ladderCuts the critical path
95% of nominal195%84%28%
80% of nominal286%73%44%
60% of nominal377%54%67%
40% of nominal464%34%84%
20% of nominal545%14%96%

The last column is the one worth carrying. Even at 80% capacity, a mild squeeze nobody would call an incident, 44% of unplanned overloads shed something on the critical path before something discretionary. A planned ladder holds that at zero all the way down to the 15% floor, where the critical path stops fitting on its own.

A worked example

Take the profile at 60 percent capacity: a node down, or a shared cluster with someone else’s job on it. Forty of the hundred units have to go.

The ladder takes three rungs. Scheduled reports off, historical trend queries off, fleet telemetry upload off. What survives is the interlock monitor, closed-loop control, anomaly detection and the live operator view, which is 77 percent of the value on 58 units. Nobody on the floor loses anything they use to run the plant.

Without a ladder the same overload keeps 54 percent of the value on average, and more to the point it sheds something on the critical path in 67 percent of cases. Not because anything went wrong, but because the interlock monitor consuming three units and the report consuming twelve are the same kind of work to a scheduler.

The rung order contains the part people argue with. Historical trends, value 2 at 22 units, comes off before fleet telemetry, also value 2 but only 8 units, because shedding the heavier one frees more capacity and means fewer capabilities have to be turned off at all. Taking the small one first would have cost a third rung for nothing.

And the profile has a floor of 15 percent. Below that, interlock monitoring and closed-loop control do not both fit, and no ordering saves it. If your real operating point ever approaches the floor, the conversation is about capacity or about how much has been labelled critical, and a ladder is not the answer to either.

The arithmetic, so you can check it

Available capacity is capacity % x total load, and shedding continues while load exceeds it. The planned order picks the lowest value at each step, breaking ties toward the heavier capability, and holds critical-path rows until nothing discretionary remains. Value retained is the surviving value as a share of the total.

The unplanned case shuffles the capabilities uniformly and sheds from the front until the load fits, averaged over two thousand runs from a fixed seed so the page reports the same figures every time. The capacity floor is critical load / total load.

The honest limit

A uniformly random order is a model of contention, not a measurement of it. Real shedding correlates with what the constrained resource is: memory pressure kills the largest consumer, a thread pool starves the most frequent caller, a saturated link drops whatever is unlucky. Uniform sits in the middle of those, so the direction of the finding is what holds rather than the exact percentage. Value on a one-to-five scale is also not additive in any rigorous sense, so read the retained-value figures as a comparison between two orderings rather than as a measure of anything on its own.

Why a degraded system still reports success is in your green dashboard is not evidence. To find how often the degraded path is taken at all, use the fallback rate estimator, and to bound what a single capability is allowed to spend, the fuse sizing tool.

Questions

What is a degradation ladder?

An ordered list of what the system turns off as headroom disappears, with the trigger for each rung and who is told. It is written before the incident, because during one there is no time to decide which of eleven capabilities matters least, and the decision then gets made by whichever queue fills first.

What happens if you have no ladder?

The system still sheds load, because something has to give. It just sheds in whatever order resource contention produces, and contention does not know which capability is safety-critical. On the reference profile, two thirds of unplanned overloads drop something on the critical path before something discretionary.

How do you decide the shed order?

Least valuable first, and among equally valuable capabilities the heavier one, because shedding it frees more capacity so fewer things have to go at all. Critical-path capabilities are held until nothing discretionary is left. The counter-intuitive part is that a heavy, moderately valuable capability often outranks a light, slightly less valuable one for shedding.

Why does a small safety-critical capability get shed first in practice?

Because size is not what protects it. A monitor consuming three percent of the budget usually sits behind the same queue, thread pool or link as the heavy discretionary work, so it starves at the same moment. Its small footprint is also why nobody thought to give it a reservation, which is precisely why it has none.

What is the capacity floor?

The share of nominal capacity the critical path needs on its own. Below it no ordering helps: even a perfect ladder has to cut into work the system cannot safely run without. If that floor is close to where you actually operate, the finding is capacity or a smaller critical set, not sequencing.