Starved vs Blocked —
Same Symptom, Opposite Cause
Both look identical from the aisle: a machine sitting still. They have opposite causes, opposite fixes, and the machine you are staring at is usually not the one with the problem.
Walk any line during a stoppage and the eye goes straight to whatever is not moving. That instinct is almost always wrong. An idle machine is a symptom, and the direction you need to walk to find the cause depends entirely on which of two states it is in.
Two states, opposite directions
- Starved — the machine has nothing to work on. It is ready, it is capable, and no material is arriving. The cause is upstream.
- Blocked — the machine has finished a unit and has nowhere to put it. It is ready, it is capable, and the exit is full. The cause is downstream.
Same appearance. Opposite diagnosis. Send a technician the wrong way and they will spend twenty minutes inspecting a perfectly healthy machine.
The buffer tells you which one it is
You do not need instrumentation to tell them apart. Look at the storage on either side of the stopped machine:
Reading the line
| What you see | State | Where the cause is |
|---|---|---|
| Buffer feeding it is empty | Starved | upstream — something is not delivering |
| Buffer after it is full | Blocked | downstream — something is not accepting |
| Both have material and it still is not running | Down | this machine — now you can look at it |
Only the third case justifies inspecting the machine in front of you. In the first two, the equipment is healthy and waiting.
This is also how you find the bottleneck. The true constraint on a line is the machine that is neither starved nor blocked — the one still running while everything around it waits. Everyone watches the stopped machines; the constraint is the busy one. That inversion is why bottlenecks get misidentified so consistently, and why the loudest complaint on a line rarely points at the real limit.
Why simulation matters here
On a real line these states blur. A machine flickers between starved, blocked and running many times an hour, and a supervisor walking past captures one instant of it. What you actually need is the proportion of time each machine spent in each state across a full run — and that is a measurement no amount of floor observation produces reliably.
Because buffers and constraints interact directly, a rate-based model produces blocking and starvation on its own: no rules to write, no logic to configure. Set the rates, the capacities and the interrupts, and the states fall out of the flow. What you get back is the time split per machine, which turns an argument about who is holding up the line into a reading.
Two things follow from that split. Heavy starvation and blocking around one machine points at your constraint. And a machine that is mostly blocked is telling you that adding capacity there would produce nothing at all — it is already making more than the next step can take.
Related: Find the real bottleneck · How big should a buffer be? · Constraints in the docs
Watch a line starve and block
The sandbox shows each machine's state over time. Stop one node and watch the effect travel in both directions.
Open the sandbox → Find your bottleneck