What Is Runner Concurrency? How Many Jobs Run at Once
Runner concurrency is the number of jobs your CI can run at the same time - the ceiling that decides whether a burst of jobs runs in parallel or backs up into a queue.
When ten jobs are triggered at once, concurrency decides how many run immediately and how many wait. Too little concurrency and your team queues; too much fixed concurrency and you pay for idle capacity. The right answer is elastic.
What sets the limit
Concurrency is bounded by how many runners are available (your fleet size or plan limit) and any per-workflow or per-org caps you configure. The effective ceiling is the smallest of these.
Concurrency and queues
When the number of triggered jobs exceeds concurrency, the surplus queues. A team that frequently sees queued jobs at peak hours has hit its concurrency ceiling, not a per-job performance problem.
The sizing trade-off
- Fixed-high concurrency: no queues, but idle capacity costs money.
- Fixed-low concurrency: cheap when idle, painful at peak.
- Elastic concurrency: autoscaling expands the ceiling on demand.
Elastic concurrency
The best answer is concurrency that scales with demand: autoscaling adds runners during bursts and removes them when idle, so you get peak throughput without paying for it off-peak. Managed platforms provide this elasticity out of the box.
Workflow-level concurrency control
Separate from fleet capacity, GitHub Actions has a concurrency key that serializes or cancels overlapping runs of the same workflow - useful for deploys you do not want running twice at once. It is a coordination tool, not a capacity tool, and the two should not be confused.
Key takeaways
- Runner concurrency is how many jobs run simultaneously.
- It is bounded by fleet size and configured caps.
- Exceeding the limit pushes surplus jobs into a queue.
- Elastic, autoscaled concurrency beats any fixed ceiling.