How to Weigh the Cost of Larger Runners
A bigger runner only saves money if the job speeds up more than the per-minute rate rises; otherwise you pay more for the same work.
Larger runners scale linearly in price with vCPU count. They pay off for parallelizable work (large test suites, native builds) and waste money on serial work.
Steps
- Measure the job duration on the standard 2-core runner.
- Run it on a larger runner and compare duration and per-minute rate.
- Keep the larger runner only if total cost (minutes times rate) drops.
Target a larger runner by label
.github/workflows/ci.yml
jobs:
build:
# Custom larger-runner label defined in org runner settings
runs-on: ubuntu-latest-8-cores
steps:
- uses: actions/checkout@v4
- run: make -j8 build # only faster if the work parallelizesGotchas
- A single-threaded job runs no faster on more cores, so you just pay the higher rate.
- The per-minute rate roughly scales with core count, so a 2x-faster job on a 4x runner costs more.
- Measure real wall-clock, not CPU time; I/O-bound jobs rarely benefit from more cores.
Related guides
How to Account for Minutes Multipliers by OSUnderstand GitHub Actions minute multipliers so you budget correctly: macOS bills at 10x and Windows at 2x th…
How to Route Cheap Jobs to Cheaper RunnersRight-size GitHub Actions runners per job so lint and formatting checks run on the smallest runner while only…