What Is a Build Queue? Where Jobs Wait for a Runner
A build queue is the line of jobs waiting for an available agent; jobs sit there until capacity frees up to run them.
When more jobs are ready than there are agents to run them, the extra jobs wait in a queue. Queue time is pure waiting: no work happens, yet the clock on your pipeline keeps ticking. Understanding the queue is key to understanding why a pipeline that "only takes five minutes" can still take twenty to come back.
Why a queue forms
A queue forms whenever demand exceeds capacity. A burst of pushes, a big matrix, or a busy time of day can all queue jobs up. The job is ready, but every agent is busy, so it waits its turn.
Queue time vs run time
- Queue time: waiting for an agent (no work done).
- Run time: the agent actually executing steps.
- Total time the developer feels = queue time + run time.
A quick example
Ten developers push at 9am and you have five agents. Five jobs run immediately; the other five queue until the first batch finishes. Each queued job's reported duration looks short, but the wait was real.
Shortening the queue
You shorten a queue by adding capacity, making jobs finish faster (so agents free up sooner), or running fewer redundant jobs. Autoscaling adds agents under load; concurrency limits and cancelling stale runs reduce demand.
Queues on managed runners
Queue time is one of the most frustrating, least visible CI costs. Managed runners (Latchkey) keep a warm pool and scale up quickly, so bursts of jobs start running with little or no time spent waiting in the queue.
Key takeaways
- A build queue holds jobs that are ready but waiting for a free agent.
- Queue time is pure waiting and adds to the pipeline time developers feel.
- Add capacity, speed up jobs, or cut redundant runs to shorten the queue.