What Is Runner Utilization? Are You Paying for Idle Time?
Runner utilization is the fraction of the runner time you pay for that is actually doing useful work - the rest is idle capacity you are burning money on.
Low utilization is the quiet CI cost. A runner that sits booted but idle, or a 16-core machine running a single-threaded job, is money spent without value returned. Measuring utilization tells you where the waste is.
Two kinds of waste
Time-based waste is runners idling while still billed (over-provisioned pools, slow scale-down). Resource-based waste is runners that are too big for the job - paying for cores and memory a single-threaded build never touches.
Why utilization drops
- Fixed pools sized for peak that idle most of the day.
- Oversized runners chosen "to be safe".
- Long provisioning or queue time counted as paid runner time.
- Sequential jobs that leave parallel capacity unused.
Raising utilization
Right-size runners to the job, autoscale and scale to zero so idle time costs nothing, and parallelize work to keep machines busy. Per-second billing also helps - you stop paying for rounded-up idle tails.
Utilization on managed runners
Managed platforms raise utilization automatically: scale-to-zero removes idle waste and right-sizing avoids oversized machines. Latchkey's per-second billing and autoscaling mean you pay for work, not idle.
Measuring it
Track active job time against total billed runner time, and compare requested runner size against actual CPU and memory used per job. A big gap on either axis points straight at over-provisioning - the cheapest CI savings are usually right there.
Key takeaways
- Utilization is the share of paid runner time doing useful work.
- Idle pools and oversized runners are the main sources of waste.
- Right-sizing, scale-to-zero, and parallelism raise it.
- Autoscaling and per-second billing align cost with actual work.