Guides
How to scale self-hosted runners
Self-hosted runners either queue at peak or sit idle and expensive.
7 min read
Self-hosted runners either queue at peak or sit idle and expensive.
Why it happens
Scaling policy has to react faster than developers notice, and scale down without killing running jobs.
How to fix it
- Scale on queue depth, not on CPU utilization
- Keep a warm pool sized to your median concurrency
- Drain rather than terminate, so in-flight jobs finish
- Cap maximum capacity so a runaway workflow cannot exhaust your quota
Your next build could be twice as fast, at half the price
Start free. Migrating away is the same one line, and we publish that diff too.
Related
How to use runner groupsAny repository can schedule jobs on any runner.How to design a runner label strategyLabels grew organically and nobody knows which to use.Hosted or BYOC: how to chooseYou are unsure whether to use hosted runners or deploy into your own cloud.How to use reusable workflows at scaleFifty repositories have fifty slightly different copies of the same pipeline.