Underpowered runners: paying more by going slow

Symptoms

How to tell if your runners are underpowered

Underpowered runners don't announce themselves with error messages. They just make everything slower. Look for these patterns:

• Builds that are far slower than local. Your laptop finishes a build in 5 minutes. The same build takes 20 minutes in CI. The default private-repo runner has only 2 vCPUs and 8 GB of RAM, which is less than most developer machines. CPU-bound steps like compilation, bundling, and type-checking hit a hard ceiling on those 2 cores.

• Build times that don't improve with parallelism settings. You set PARALLEL_WORKERS=8 or make -j8, but the build doesn't get faster. On a 2-core runner, requesting 8 threads of parallelism just causes contention. The CPU is already maxed out.

• Unexplained OOM kills or signal 9 failures. Your CI job dies with Killed or exits with code 137. The standard private-repo runner has only 8 GB of RAM. Large TypeScript compilations, Webpack builds, and Docker multi-stage builds can exhaust this, causing the Linux OOM killer to terminate the process.

• High runtime variance between runs. The same build takes anywhere from 12 to 25 minutes on different runs. GitHub's standard runners use shared AMD EPYC processors with variable clock speeds. When you're CPU-bound, this variance translates directly into unpredictable costs and unreliable feedback loops.

Metrics

When a bigger runner costs less

The intuition that "smaller runner = cheaper" is wrong for CPU-bound workloads. What matters is total cost per job: minutes × rate. If a larger runner cuts minutes enough, the total drops despite the higher rate. Here's the math for a compilation-heavy workflow:

The 4-core runner costs 2× per minute but finishes in 40% of the time. Total cost drops 20%, and developers get feedback in 8 minutes instead of 20. On macOS runners at $0.062/min, the same pattern saves dramatically more. If a macOS build drops from 20 to 8 minutes, that's $14.88 saved per run.

The break-even rule: a runner that costs N× more per minute must finish in less than 1/N of the time to save money. A 4-core at 2× the rate needs to finish in under 50% of the time. An 8-core at 3.67× the rate ($0.022 vs $0.006) needs to finish in under 27%. CPU-bound parallel workloads regularly clear these thresholds.

Fix 1

Measure runner utilization before resizing

Before changing runner sizes, confirm the runner is actually the bottleneck. Add resource monitoring to your workflow to see CPU and memory utilization during the build. If CPU is pegged at 100% during compilation or testing, a larger runner will help. If the job is mostly waiting on network calls or external services, more cores won't change anything.

The catchpoint/workflow-telemetry-action collects CPU load, memory usage, network I/O, and disk I/O throughout your job and posts the results as graphs in the job summary and on the PR. No external services required.

jobs:
  build:
    runs-on: ubuntu-latest
    permissions:
      pull-requests: write
    steps:
      - uses: catchpoint/workflow-telemetry-action@v2
        with:
          comment_on_pr: true

      - uses: actions/checkout@v5
      - run: npm ci
      - run: npm run build
      - run: npm test

If you want a quick diagnostic without adding a dependency, add a manual monitoring step. This logs the available cores, memory, and disk before and after your build:

steps:
  - name: System info
    run: |
      echo "CPUs: $(nproc)"
      free -h
      df -h /

  - name: Build with timing
    run: time make -j$(nproc) build

  - name: Post-build resources
    run: |
      free -h
      uptime

Look for nproc returning 2 (confirming you're on a standard private-repo runner), memory usage above 80%, or a build time that's mostly CPU-bound work. If uptime shows load averages above 2.0 on a 2-core machine, the runner is saturated.

Fix 2

Upgrade CPU-bound jobs to larger runners

Once you've confirmed the job is CPU-bound, switch the runs-on label to a larger runner. Start with a 4-core runner, which is the most cost-effective upgrade for most workloads because it doubles compute at 2× the rate, and CPU-bound builds typically see more than a 2× speedup due to reduced OS scheduling overhead and more memory bandwidth.

Team / Enterprise Cloud Larger runners require a GitHub Team or Enterprise Cloud plan. They are not available on Free or Pro plans, and they are always billed per-minute. Included plan minutes cannot be used.

jobs:
  build:
    runs-on: ubuntu-latest
    # 2 vCPUs, 8 GB RAM
    # 20 min build → $0.120
    steps:
      - uses: actions/checkout@v5
      - run: make -j$(nproc) build

jobs:
  build:
    runs-on: ubuntu-22.04-4core
    # 4 vCPUs, 16 GB RAM, 150 GB disk
    # 8 min build → $0.096
    steps:
      - uses: actions/checkout@v5
      - run: make -j$(nproc) build

The runs-on label is the only change. Your build commands already use $(nproc) to detect available cores, so they'll automatically use the additional CPUs. The 4-core runner also comes with 16 GB of RAM and 150 GB of disk, providing 10× the storage of a standard runner, which eliminates OOM kills and disk-full errors on Docker builds.

One caveat: not every job benefits from more cores. Steps that are I/O-bound (downloading dependencies, pushing artifacts) or single-threaded (some linting tools) won't run faster on a larger runner. Apply larger runners selectively to the jobs that are CPU-bound, not to your entire workflow. If you go too far in the other direction, you end up with overpowered runners, paying for CPU and RAM your jobs never use.

Fix 3

Switch to ARM64 runners for lower per-minute cost

ARM64 Linux runners are priced roughly 37% lower than their x64 equivalents at every core count. If your build doesn't depend on x86-specific tools or native extensions, this is the easiest cost reduction available. An 8-core ARM64 runner costs $0.014/min vs $0.022/min for an 8-core x64, delivering the same compute at 36% less per minute.

Team / Enterprise Cloud ARM64 larger runners require GitHub Team or Enterprise Cloud. ARM64 2-core runners are available in public preview for public repos on any plan.

jobs:
  build:
    runs-on:
      labels: ubuntu-22.04-arm-4core
    steps:
      - uses: actions/checkout@v5
      - run: npm ci
      - run: npm run build
      - run: npm test

Most Node.js, Python, Go, Java, and Ruby workloads run on ARM64 without changes. Native extensions that compile C code may need ARM-compatible toolchains. Docker builds targeting linux/arm64 run natively instead of through QEMU emulation, which can be 5–10× faster than cross-building on x64.

One caveat: ARM64 runners have slightly different software pre-installed than x64 runners. Test your workflow on ARM64 before committing to the switch. If a specific step fails, you can split your workflow and run only the CPU-bound jobs on ARM64 while keeping other jobs on x64.

Fix 4

Use different runner sizes for different jobs

Not every job in your workflow needs the same runner. A linting step that takes 30 seconds doesn't need a 16-core machine. A compilation step that takes 15 minutes does. Map each job to the smallest runner that keeps it CPU-unconstrained. This is the difference between right-sizing and over-provisioning.

jobs:
  lint:
    runs-on: ubuntu-latest          # 2-core is fine
    steps:
      - uses: actions/checkout@v5
      - run: npm run lint

  build:
    runs-on: ubuntu-22.04-4core       # CPU-bound compilation
    steps:
      - uses: actions/checkout@v5
      - run: npm ci
      - run: npm run build

  test:
    runs-on: ubuntu-22.04-8core       # Parallel test suite
    steps:
      - uses: actions/checkout@v5
      - run: npm ci
      - run: npm test -- --shard=1/1

  docker:
    runs-on: ubuntu-22.04-4core       # Needs disk + RAM
    needs: [lint, build, test]
    steps:
      - uses: actions/checkout@v5
      - run: docker build -t app .

In this workflow, linting stays on the cheapest runner. The build job gets 4 cores for compilation. The test suite gets 8 cores to parallelize across. The Docker build gets 4 cores plus the extra disk and RAM that come with larger runners (150 GB disk vs 14 GB). Each job uses and pays for only what it needs.

Reference

GitHub Actions larger runner rates

These are the per-minute rates as of January 2026, after GitHub's pricing reduction. See the GitHub Actions billing docs for the latest rates. Larger runners also include proportionally more RAM and disk: a 4-core gets 16 GB RAM and 150 GB disk, and a 16-core gets 64 GB RAM and 600 GB disk.

Larger runners also scale RAM and disk proportionally. A 4-core runner has 16 GB RAM and 150 GB SSD. A 16-core has 64 GB RAM and 600 GB SSD. These extra resources eliminate OOM kills and disk-full failures that force expensive reruns on standard runners. For teams running on self-hosted infrastructure, see our guide on always-on self-hosted runners for an alternative approach to right-sizing.

Standard runner included minutes (2,000 Free, 3,000 Team, 50,000 Enterprise) cannot be used for larger runners. Larger runners are always billed per-minute, even for public repositories.