May 19, 2026
5 min read
Flow metrics
Queue Time vs Cycle Time
The difference between queue time and cycle time, why teams confuse them, and what each one reveals about the delivery system.
Why this distinction matters
Teams often talk about work being slow without being clear about where the slowness actually lives. That is why queue time and cycle time matter. They separate two different parts of the delivery experience instead of flattening everything into one vague delay.
The distinction becomes especially useful when a team feels overloaded, reviews are backing up, or delivery looks acceptable from a distance but still feels frustrating up close.
Time split
Queue time and cycle time answer different questions about how work moves and waits.
Waiting time
Queue time helps teams see how much delay exists before the work even starts moving through the active delivery steps.
Active delivery time
Cycle time is about how long work takes once it actually enters the delivery path and starts moving.
Elapsed from start to finish
The two metrics together explain whether delay is coming from waiting to begin or from slow movement after start.
Cleaner diagnosis
Separating them helps teams focus improvement work on the specific kind of delay they are really facing.
Better insight
A team gets more useful action from metrics when it knows which kind of time it is actually trying to shorten.
What queue time actually measures
Queue time measures how long work sits waiting before or between active steps. It captures review backlog, approval delay, dependency waiting, batching, and all the other forms of idle time that quietly accumulate in a delivery system.
That makes it a strong lens for hidden delay. If people keep saying work feels stuck, queue time often helps explain why.
What cycle time actually measures
Cycle time measures the full elapsed journey once work enters the system until it is finished. It gives the broader external view of how long delivery takes overall.
That broader view is still useful. It helps with forecasting and with comparing overall movement over time. It just does not tell you on its own where the wasted time is hiding.
Why teams confuse them
The two metrics are related, so they often get lumped together. But a team can have acceptable-looking cycle time while still wasting a surprising amount of time in queues. That is why breaking elapsed time apart matters.
Without that split, delay can disappear inside a broader average and stay oddly invisible even when everyone feels it.
How to use both together
The healthiest move is not picking one metric and ignoring the other. Use queue time when you want to inspect waiting behavior. Use cycle time when you want to inspect the full elapsed delivery experience.
- Use queue time to inspect waiting and hidden delay.
- Use cycle time to inspect full elapsed delivery.
- Use both together when you want a clearer picture of system behavior.
TL;DR
- Queue time measures waiting before or between active steps.
- Cycle time measures the full elapsed journey from start to finish.
- Queue time is often the sharper lens when teams want to understand hidden delay.
- Cycle time is still useful for the broader view of delivery speed and forecasting.
- Teams diagnose delivery problems better when they separate waiting time from active working time instead of collapsing both into one story.