GitHub Actions runner cost by size

By Daniel Zoghalchali·Latchkey

A GitHub Actions runner cost comparison that stops at the per-minute rate answers the wrong question, because you do not buy minutes, you buy finished jobs. The number that decides a size is the rate multiplied by the minutes the job bills after rounding, and this page does that arithmetic across GitHub's ladder and against two other published rate cards read the same day.

The rule everyone repeats is that a bigger runner pays for itself if it halves the job. Close, and close is expensive: the threshold is the ratio between two published rates, and GitHub's ladder does not double cleanly at every step.

There is also a second effect that no rate card mentions. Because every job is rounded up to a whole minute, a genuine speedup can still lose money on a short job, and the arithmetic below shows exactly where that happens.

The only formula on this page

The cost of a job is its rate multiplied by its billed minutes, and its billed minutes are its duration rounded up to the next whole minute. Everything below is that one line applied to different rates and different durations.

What makes it useful is the inversion. You rarely know what a job will take on a machine you have not tried, but you always know what it takes now, so the question is not "how fast will it be" but "how fast does it have to be". The two rates fix that, and you can read it off before running anything.

What each step up the ladder has to buy

Divide the rate you are moving to by the rate you are moving from and you get the speedup the job must deliver just to break even. On GitHub's Linux x64 ladder that number is not a constant, because only the first step doubles exactly.

The cheapest step to justify is 8 cores from 4: the rate rises by a factor of 1.83, so the job only has to finish in 54.5 percent of the time rather than half of it. The hardest is 4 cores from 2, which is a clean doubling and therefore demands a clean halving. The step from 64 to 96 looks generous at 64.3 percent, but it buys only 50 percent more cores, so it is easy to hit only if the job was memory-bound in the first place.

A 24-minute job, sized four ways

Take a test suite that bills 24 minutes on the standard 2-core Linux runner, which is $0.144 a run. Now apply the thresholds above, but round each candidate up to whole minutes the way the meter does, and the answer sharpens into a target you can hold a stopwatch to.

On the 4-core runner, 12 billed minutes costs exactly the same $0.144, so 12 minutes is a tie and the job has to come in at 11 to be worth the move. On the 8-core runner the job has to bill 6 minutes, and on the 16-core it has to bill 3. Measure your own suite at one size up before you commit the whole matrix to it.

Rounding decides the marginal cases, and it decides them against you

Here is the case that catches people who did the arithmetic correctly. A job bills 11 minutes on the 2-core runner, which is $0.066. You move it to the 4-core runner and it genuinely halves, finishing in 5 minutes 30 seconds. The meter rounds that to 6 minutes, and 6 at $0.012 is $0.072. A perfect doubling of speed made the job 9.1 percent more expensive.

A 12-minute job in the same move lands on exactly $0.072 either way. Below about 12 minutes, in other words, a larger runner needs to beat the rate ratio rather than merely match it, and the shorter the job the wider that gap gets.

The corollary is worth stating because it runs against the usual advice: on a short job, the cheapest move is almost never a bigger machine. It is fewer jobs. Minutes and billing explained has what per-job rounding costs a wide matrix.

The same job on three published rate cards

Now hold the job still and change the vendor. Below is what 24 billed minutes costs at each size on three price lists read on 20 September 2026: GitHub's larger Linux x64 runners, Depot's GitHub Actions runners, and Latchkey's Linux runners. The job does not speed up between columns; only the rate changes.

The shapes differ, and the difference is the point of a comparison by size. Depot's ladder doubles exactly at every step, so it matches GitHub at 2 and 4 vCPU and then costs more: 9.1 percent more at 8 vCPU and 14.3 percent more at 16. Latchkey's ladder also doubles exactly, from a lower base, so its gap against GitHub narrows as the machine grows, from 58.3 percent cheaper at 2 vCPU to 52.4 percent at 16.

A month, with the plan fee on the table

Scale that job to 400 runs a month at 24 billed minutes, which is 9,600 minutes, and put it on an 8 vCPU machine. On GitHub's 8-core larger runner at $0.022 the month is $211.20, and none of it can be paid with included minutes, because included minutes cannot be used for larger runners. On Depot at $0.024 it is $230.40.

On a Latchkey large runner at 8 vCPU and 32 GB, the compute line is $96.00 at the published $0.01 a minute. On top of that sits the monthly plan fee: $5 on Developer, $19 on Launch, $49 on Scale. Latchkey's own included minutes, 2,000 to 6,000 a month by plan, are not netted off here, so the all-in month is $101 to $145 against GitHub's $211.20, which is 31 to 52 percent lower depending on which plan you are on.

Two honest qualifications. Latchkey's published price list has no Windows, macOS or arm64 runner, so those jobs are not in this comparison at all and stay where they are. And the compute gap narrows as the machine grows, so the case is strongest at the sizes most pipelines actually use. How Latchkey cuts the GitHub Actions bill sets out the rest of the argument.

How to run this for your own job

Take one workflow, not the whole pipeline. Read its billed minutes from the detailed usage report, which is already rounded the way the invoice is, and multiply by the runner's rate.

Then look up the step you are considering in the table above, take the percentage, and multiply your current duration by it. That is the wall-clock number the bigger machine has to beat, and if the result is under about twelve minutes, subtract a minute for rounding before you believe it.

Then run the job once at each of two sizes and compare durations in the run summary. One measurement on your own repository is the only input the arithmetic above is missing. If the machine turns out not to be the problem, reduce GitHub Actions costs ranks the changes that are.

# Measure the same job at two sizes in one run, then compare durations
jobs:
  suite-standard:
    runs-on: ubuntu-latest
    timeout-minutes: 45
    steps:
      - uses: actions/checkout@v7
      - run: make test

  suite-larger:
    runs-on: ubuntu-latest-4-cores
    timeout-minutes: 45
    steps:
      - uses: actions/checkout@v7
      - run: make test

Key takeaways

• Cost per job is the rate times the billed minutes, and billed minutes are always rounded up.
• The break-even speedup is the ratio of the two rates: 50.0% at the first step, 54.5% at the second.
• Below about twelve minutes, rounding means a perfect doubling of speed can still cost 9.1 percent more.
• Depot matches GitHub at 2 and 4 vCPU and costs 9.1 to 14.3 percent more at 8 and 16.

Frequently asked questions

Related guides

References

• GitHub: Actions runner pricing, per-minute rates by size and the rounding rule (verified 2026-09-20)
• Depot: GitHub Actions runner types and per-minute prices by size (verified 2026-09-20)
• GitHub: larger runner specifications by vCPU, RAM and disk (verified 2026-09-20)
• GitHub: usage report types and the billed-minute columns (verified 2026-09-20)
• Latchkey pricing: published per-minute runner rates and plan fees (verified 2026-09-20)
• GitHub Actions documentation