Queue Time in Manufacturing

Queue time is the time a part spends waiting to be worked on, sitting in front of a machine that is busy or not yet ready. It is pure waiting, no cutting, filling, or assembly happens during it, and in most plants it is the single largest slice of total lead time.

Here is the uncomfortable part: a job that takes four minutes of actual machine time can spend two days in the building. The machine minutes are easy to see and easy to improve. The waiting is invisible, uncounted, and usually far larger. This guide explains what queue time is, why it dominates lead time, why it explodes as a line runs closer to full, and what actually shortens it.

What is queue time in manufacturing?

Queue time is the portion of a part's journey spent waiting in line for a resource, a machine, an operator, an inspection, a lift truck, while that resource is occupied or unavailable. It is one component of total lead time, alongside run time (actual processing), setup time, move time, and wait time for other reasons.

The clean way to see it: manufacturing lead time = queue + setup + run + move + inspect. Only run time adds value. Everything else, queue time most of all, is a part sitting still while the clock runs. That is why lead time and cycle time can be wildly different numbers, and why cutting machine cycles by 10% often does nothing to the lead time a customer feels.

A concrete example makes the scale obvious. Say a component needs six operations, each with four minutes of run time, 24 minutes of value-added work in total. If that component takes three days to move through the plant, its value-added ratio is roughly 24 minutes out of 4,320, under 1%. The other 99% is queue, move, and wait. An improvement team that spends a month shaving a minute off each machine cycle has attacked less than 1% of the lead time. The team that halves the queues has attacked the other 99%.

Why do parts spend most of their lead time in queue?

Because plants have more parts than machines, and parts arrive faster and more unevenly than any single machine can absorb. Whenever work shows up in bursts, a batch drops, a shift starts, a rush order jumps the line, the parts that cannot be worked immediately wait. Multiply that across every station and the waiting stacks up. It is common for value-added time to be a low single-digit percentage of total lead time; the rest is queue and other waiting.

Two things drive queue length: how heavily a resource is loaded, and how variable the arrivals and processing times are. Load it lightly and there is usually a free machine, so parts flow. Load it near its limit and every burst of arrivals has nowhere to go but the line. Add variability, breakdowns, uneven batch sizes, quality holds, and the queues get longer still, because the machine keeps falling behind and never fully catches up before the next surge.

Batch sizes make this worse in a way that is easy to miss. When work moves in large batches, every part in the batch waits for the whole batch to finish the previous step before any of them move to the next. A part that took two minutes to process can wait an hour for the ninety-nine parts behind it in the same batch. Large batches feel efficient at the machine because setups are amortized over more parts, but they manufacture queue time everywhere downstream. This is the tension at the heart of lead-time work: local efficiency at one station and short queues across the line often pull in opposite directions.

Why does queue time explode as utilization nears 100%?

Because waiting time does not rise smoothly with load; it curves upward and then shoots vertical. The relationship is captured by Kingman's formula which approximates the average wait at a single resource as a product of three things: a utilization term, a variability term, and the processing time. The utilization term is the killer. It behaves like ρ ÷ (1 − ρ), where ρ is utilization, and that fraction blows up as ρ approaches 1.

The arithmetic is blunt. Holding variability constant, the utilization multiplier looks like this:

Going from 90% to 95% utilization does not add 5% to the wait; it roughly doubles it. This is why a plant that "runs everything flat out" often has the worst lead times and the biggest work-in-process piles. Chasing 100% utilization at a non-bottleneck resource buys almost nothing in output and pays for it in queue.

How is queue time related to WIP and Little's law?

Queue time and inventory are two views of the same thing, tied together by Little's law: work-in-process = throughput × flow time. Longer queue time means longer flow time, which means more WIP sitting on the floor at any moment. Cut queue time and WIP falls with it; let queue time balloon and the floor fills with parts tying up cash and space.

This is the practical link between queue time and money. Every hour a part waits is an hour it counts as inventory. A plant that pushes utilization toward 100% to protect capacity utilization often discovers it has traded a slightly higher machine number for a much larger WIP pile and a longer promise to customers. The bottleneck sets the real throughput; loading the non-bottlenecks to the ceiling only grows their queues.

The theory of constraints sharpens the point. An hour lost at the bottleneck is an hour lost for the whole plant, so the bottleneck should never wait for work, a small, deliberate queue in front of it is protective. An hour lost at a non-bottleneck is free, because that resource has spare capacity anyway, so a queue in front of it buys nothing but WIP and lead time. The mistake most plants make is treating every station as if it were the constraint and loading them all to the ceiling, which builds queues everywhere the constraint cannot use. Queue belongs in exactly one place: just ahead of the bottleneck, sized to keep it fed and no larger.

How do you reduce queue time?

Reducing queue time is mostly about lowering load at the right places, cutting variability, and moving work in smaller, steadier increments. A dependable sequence:

1. Find the bottleneck and protect it. Queue that matters most builds in front of the constraint. Use bottleneck analysis to locate it, then keep it fed and running rather than loading every other station to the ceiling.
2. Pull utilization back from the edge on non-bottlenecks. Running a non-constraint at 95% instead of 99% costs almost no output and cuts its queue dramatically. Deliberate slack is a lead-time tool, not waste.
3. Shrink batch sizes. Big batches force everything behind them to wait for the whole batch. Smaller transfer batches let parts move sooner and flatten the arrival surges that build queues.
4. Attack variability. Breakdowns, long changeovers, and quality holds all make queues longer than utilization alone predicts. Reducing machine downtime and changeover time steadies the flow.
5. Cap work-in-process. A WIP limit or pull system stops the floor from releasing more work than the constraint can absorb, which by Little's law holds flow time down.
6. Make queues visible. Post where parts are waiting and for how long. A queue no one can see is a queue no one manages, and it quietly becomes the largest part of your lead time.

How does queue time connect to OEE and the plant?

Queue time does not appear directly in OEE OEE measures a machine while it is running, not the parts waiting for it, but the two are joined at the hip. High utilization looks good on paper and can even lift a single machine's OEE, while quietly building the queues that stretch lead time and bury the floor in WIP. That is why OEE alone is a narrow scoreboard, and why queue time and lead time belong beside it on the manufacturing KPI board.

The reason queue time stays invisible in most plants is simple: nobody is timing it. A part's wait starts and ends without a transaction, so it never lands in a report. Plants that capture start and finish at each step digitally, the way Harmony logs production activity at the point of work and feeds live production reporting (see the platform), can finally see where parts wait and how long, which is the first requirement for cutting it. The CLS case study shows what that shift from paper to real-time capture looks like on a working floor.