How to Use a Warm Pool to Cut Runner Cold Starts in GitHub Actions

A warm pool keeps a few runners booted and registered ahead of demand, so the next job runs immediately instead of waiting on a cold scale-up.

Maintain a minimum number of idle, registered runners. When a job arrives it lands on a warm runner instantly; the autoscaler then replenishes the pool in the background.

Steps

• Set a minimum pool size of idle, registered runners.
• Route jobs to the warm runners via labels.
• Replenish the pool asynchronously after each job is claimed.
• Tune the minimum against your queue depth and budget.

Minimum pool (ARC example)

# gha-runner-scale-set values.yaml
minRunners: 3      # keep 3 warm, idle runners
maxRunners: 30
# A queued job lands on a warm runner; the set scales back to minRunners.

Gotchas

• A warm pool trades a little idle cost for big latency wins; size it to your typical concurrent demand.
• Pure scale-to-zero setups have the worst cold starts; a small minimum fixes most of it.
• Latchkey runs a managed warm pool for you, so jobs avoid cold starts without you tuning minimums or paying for idle hardware directly.

Related guides