What Is a Runner Queue? Why Jobs Wait Before They Run
A runner queue is the line of jobs waiting for a free runner - every second a job spends queued is time before your first step even begins.
When you have more jobs than available runners, the extra jobs queue. Queue time is pure waste: nothing is building, nothing is testing, your team is just waiting. Understanding why queues form is the first step to removing them.
Why queues form
- Concurrency limits: your plan or fleet caps how many runners run at once.
- Slow scaling: a burst arrives faster than autoscaling can add runners.
- No warm capacity: every job pays a cold start, so throughput lags demand.
- Label mismatch: jobs request a runner type that has no available capacity.
How to read queue time
Queue time is the gap between a job being created and actually starting (started_at minus created_at). A consistently high gap means a capacity or scaling problem, not a problem with your build itself.
The cost of queueing
Queues slow your whole team: longer feedback loops, blocked merges, and pressure to disable checks. They are often invisible in CI bills (you do not pay for queued time) but very visible in developer frustration.
How to eliminate it
Add capacity (autoscaling), remove cold starts (warm pools), and right-size concurrency. The combination of warm pools plus fast autoscaling is what keeps the queue empty even during bursts.
No-queue runners
Latchkey serves jobs from warm pools and autoscales, so jobs typically start in about a second with no queue - even when several land at once.
Key takeaways
- A runner queue is jobs waiting for an available runner.
- It is caused by concurrency limits, slow scaling, or no warm capacity.
- Queue time is started_at minus created_at - pure wasted feedback time.
- Warm pools plus autoscaling keep the queue empty.