How to Cut Your GitHub Actions Bill Without Slowing Builds

You can cut your GitHub Actions bill without slowing builds in two ways. Move each job to a same-size WarpBuild runner at a lower per-minute rate, so it keeps its vCPU count and memory. Then cut wasted minutes from superseded runs, re-runs and cold caches, which makes builds cheaper and faster. Only downsizing can slow a build, so measure first.

How to cut CI cost without slowing buildsCopy Anchor Link

Two moves lower the bill without taking CPU or memory from the job. A third move, downsizing, can slow a build and needs measurement.

Work through them in this order:

1. Measure where the minutes go, so every later change has a number to check against.
2. Move each job to the same-size WarpBuild label.
3. Cancel superseded runs, fix flaky tests and keep caches warm.
4. Right-size only the jobs that measurement shows are over-provisioned, and check duration after each change.

None of these steps needs a workflow rewrite. If your goal is speed first and cost second, read Can you cut GitHub Actions build times?.

Which savings keep the job's CPU and memoryCopy Anchor Link

A same-size runner lowers the rate, and cutting wasted minutes removes work that does nothing useful. Neither takes CPU or memory from the job.

Same size, lower rateCopy Anchor Link

On a WarpBuild runner of the same size, the job keeps the same vCPU count and memory at a lower per-minute rate. The table compares GitHub's list prices on its minute-multipliers reference and specs on its GitHub-hosted runners and larger runners references with WarpBuild's cloud runners docs and pricing page.

Every WarpBuild Linux x64 size has a 150GB SSD, against 14GB on GitHub's standard runner. GitHub's 8-core and larger runners have 300GB or more, so check disk use before you move a job off them.

The WarpBuild Linux x64 images have the same tooling as GitHub-hosted runners, per the cloud runners docs. If a build compiles and tests cleanly on ARM64, the ARM64 labels cost less again. warp-ubuntu-latest-arm64-2x bills $0.003 per minute and warp-ubuntu-latest-arm64-8x bills $0.012 per minute, with the same vCPU and memory as the x64 label of the same size.

On Windows x64, WarpBuild runners from 4 to 32 vCPU bill less per minute than GitHub's Windows x64 runners of the same size. GitHub's 2-core Windows runner ($0.010 per minute) has no same-size match, and the smallest WarpBuild Windows runner is $0.016 per minute (pricing, GitHub rates).

Cancel superseded runsCopy Anchor Link

When a new commit lands on a pull request, the run for the older commit no longer matters. Without a concurrency group it still bills to the end. Add a concurrency group and turn on cancel-in-progress for pull request events only, so a run on main that has already started is not cancelled. The YAML is in the workflow section below. This cuts minutes and frees runners for the run you care about.

Fix flaky re-runsCopy Anchor Link

Every failed run that needs a manual re-run bills its full duration again. For example, if a flaky suite forces a re-run on 15 percent of pushes, that workflow's billed minutes rise by about the same share. Rank jobs by the Success column on the WarpBuild Jobs page and fix the flakiest suites first. Re-run Storms and What They Cost covers this in more depth.

Keep caches warmCopy Anchor Link

A cache miss sends the job down the cold install path, which costs build minutes. WarpBuild's cache is enabled by default on its Linux runners. Windows jobs keep actions/cache. The caching docs cover key design and the drop-in cache action. A stable cache key keeps routine runs on the warm path.

Remove idle waitsCopy Anchor Link

Billed minutes track wall clock, and wall clock includes waiting. A job that waits on a service container health check, polls an external deploy or runs a fixed sleep bills those minutes at the same rate as real work. Look for steps whose duration is long compared to their log output. Replace fixed sleeps with condition polling, and move long external waits out of billed jobs. Idle Time Inside GitHub Actions Jobs has more detail.

When a smaller runner slows a buildCopy Anchor Link

A smaller runner slows a build when the job needs the CPU or memory you take away. Downsizing is still worth doing for jobs that do not use their runner, but it is the one step that needs measurement before and after.

The WarpBuild Recommendations page lists jobs that could run faster or cheaper on a different runner. It shows the current label, a suggested label and CPU and memory at P90. It flags runners as under-provisioned when sustained CPU, memory, filesystem use or disk I/O reaches 80 percent or more. These metrics need observability enabled, and observability only collects data for jobs longer than about one minute.

Use it like this:

1. Pick a job the Recommendations page marks as over-provisioned.
2. Note its duration P90 on the Jobs page.
3. Move it one size down by changing runs-on.
4. After a week, check duration P90 again. Keep the smaller size only if duration holds.

If duration P90 grows enough to cancel the lower rate, move back up. Under-provisioned jobs are the reverse case. Moving them up one size can make them faster and sometimes cheaper. Right Sizing GitHub Actions Runners covers sizing per workload.

Where the money goesCopy Anchor Link

Before you change anything, find the few jobs that make up most of the bill. On GitHub, the Metered usage page lets you filter and group usage and email yourself a usage report, as described in viewing your usage of metered products.

On WarpBuild, the CI tab of the Spend page lists each job run with its repository, runner label, execution time, billed time and cost. It filters by repository, runner label, stack and job name, and shows a daily cost chart grouped by repository or runner label. Sort by cost and export the CSV. The top rows are your worklist.

The Jobs page groups runs by repository, workflow and job name. It shows run count, success rate, and duration, queue time, CPU and memory at P75 or P90. Success rate points at re-run waste. Duration P90 is the number to watch when you right-size.

If macOS is a large part of your usage report, see what macOS runners cost on GitHub Actions. For data transfer charges from deploy-heavy workflows, see GitHub Actions Egress Costs, Explained.

What the workflow change looks likeCopy Anchor Link

The rate change is one line in each job:

 jobs:
   test:
-    runs-on: ubuntu-latest
+    runs-on: warp-ubuntu-latest-x64-2x

Pick the label that matches the current runner's size. The Linux x64 sizes, from the cloud runners docs:

A complete workflow with the label change and superseded-run cancellation:

name: ci
on:
  pull_request:
  push:
    branches: [main]

concurrency:
  group: ci-${{ github.ref }}
  cancel-in-progress: ${{ github.event_name == 'pull_request' }}

jobs:
  test:
    runs-on: warp-ubuntu-latest-x64-2x
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v7
        with:
          node-version: 22
      - run: npm ci
      - run: npm test

The concurrency block cancels the older pull request run when a newer commit lands on the same branch. A run on main that has already started is not cancelled. The label moves the job to a same-size runner. Nothing else in the file changes, and rolling back means restoring the previous label.

A worked monthly modelCopy Anchor Link

This example shows the like-for-like move first, then the waste and right-sizing steps. GitHub list prices come from its minute-multipliers reference. WarpBuild rates come from the pricing page. Example assumptions:

• 6,000 standard jobs per month averaging 8 billed minutes each, on GitHub's standard 2 vCPU Linux runner at $0.006 per minute
• 1,000 heavier jobs per month averaging 12 billed minutes each, on GitHub's 8 vCPU Linux larger runner at $0.022 per minute
• Included usage is ignored. GitHub says eligible larger-runner usage on Team and Enterprise Cloud can draw from included value, so subtract your own included usage if you have it

The current monthly bill:

Step 1 moves the same jobs to same-size WarpBuild labels:

The like-for-like move takes the bill from $552.00 to $384.00, a difference of $168.00 per month or $2,016 per year.

Step 2 cuts wasted minutes. Suppose warm caches bring the standard job from 8 billed minutes to 6. That line drops from 48,000 minutes to 36,000, and its cost from $192.00 to $144.00. The monthly total falls to $336.00, and those builds also finish 2 minutes sooner on average.

Step 3 is right-sizing, the step that needs measurement. Suppose the Recommendations page shows the heavier job peaking at 30 percent CPU and 30 percent memory on 8 vCPU. Moving it to warp-ubuntu-latest-x64-4x at $0.008 per minute cuts that line from $192.00 to $96.00, and the monthly total to $240.00. This holds only if duration P90 stays the same after the change. If the job runs longer on 4 vCPU, part of that saving goes away.

Against the original $552.00, this example ends at $240.00 per month after all three steps, or $336.00 if you skip right-sizing.