How to Factor Queue Time Into Choosing a Runner
Total feedback time is queue time plus run time; a faster runner that you wait longer to get can be slower end-to-end than a standard runner that starts immediately.
A larger or specialized runner may have a smaller pool, so jobs wait longer to start. When you compare options, measure the time from job created to job started, not just the run duration.
Measure queue time
# started_at minus created_at per job = queue time
gh api repos/my-org/my-repo/actions/runs/$RUN_ID/jobs \
--jq '.jobs[] | {name, created: .created_at, started: .started_at}'Why specialized runners queue
GPU, large-size, and self-hosted runners typically have fewer instances than standard Linux. If demand spikes, jobs wait. A standard runner that starts in seconds can beat an 8-core runner that waits minutes for capacity.
Reduce queueing
Scale your self-hosted pool to peak demand, or use elastic managed runners that add capacity on demand so queue time stays near zero. Right-sizing here is about availability, not just speed.