GitHub Actions pricing in 2026 and how to lower your bill
Those rates have applied since January 1, 2026, when GitHub cut hosted-runner prices by up to 39%. After the included allowance, runner charges depend on each job's runtime, rounded up to a whole minute, and the runner's rate.
To lower the bill, start by canceling outdated runs and cutting retries, check that each job is on the cheapest runner that can do it, and then compare what the same workflow costs on another provider.
Free usage and included minutes
GitHub doesn't charge for:
- standard GitHub-hosted runners in public repositories
- jobs on self-hosted runners in any repository, public or private (you pay for the machines, not for Actions)
- GitHub Pages and Dependabot jobs on standard runners
Private repositories get a monthly allowance, set by the plan of the account that owns the repository.
The allowance resets to the full amount at the start of each billing cycle, and it only covers standard runners. Larger runners are billed from the first minute, in public repositories too. If the account has no payment method on file, jobs stop running once the allowance is used. With one, usage continues at the per-minute rates unless a budget set to stop usage at its limit runs out. A budget without that setting only sends alerts.
Usage is charged to the owner of the repository, not to the person who triggered the run.
GitHub's docs count a minute on the standard 2-core Linux runner as one minute of the allowance. They no longer say how Windows or macOS minutes are counted. Until December 2025 the billing page listed a multiplier of 2 for Windows and 10 for macOS, which were the price ratios at the time, and in the FAQ to its December 2025 pricing announcement GitHub said standard runners use up the allowance based on their list price. GitHub doesn't publish current multipliers, so check the usage page in your billing settings to see how fast your account's allowance is being used.
Source: GitHub Actions billing, checked October 2, 2026.
GitHub-hosted runner pricing
Standard runners are what you get from labels such as ubuntu-latest, windows-latest and macos-latest.
Larger runners are available on the Team and Enterprise Cloud plans and are priced by core count. The table shows 4 cores and up.
Source: GitHub's Actions runner pricing reference, checked October 2, 2026.
From 4 to 64 cores, the Linux x64 rate works out to $0.002 plus $0.0025 per core, which is why doubling the cores doesn't quite double the price. Linux arm64 follows the same pattern at $0.0015 per core and Windows x64 at $0.005. The flat $0.002 matches the platform charge that GitHub says is included in every hosted-runner rate.
How billed minutes are calculated
GitHub rounds every job up to the next whole minute. The rounding is per job, not per workflow run, so the number of jobs matters as well as how long they take.
Take a workflow with three jobs on standard Linux runners. The durations are invented to show the arithmetic.
The run used 10 minutes 5 seconds of runner time and is billed as 12 minutes.
Now split the unit tests into four parallel shards. The pull request gets its result sooner, but each shard repeats the checkout and the dependency install, and each one is rounded up separately. If the shards take 2 minutes 10 seconds each, that's four jobs billed at 3 minutes. The tests used to cost 7 billed minutes and now cost 12.
At 30 runs a working day, the original workflow uses about 7,560 billed minutes a month (30 runs, 21 days, 12 minutes). On the Team plan the first 3,000 are included and the remaining 4,560 cost $27.36.
A job that fails is still billed for the time it ran, and so is every re-run. GitHub's own example is a 10-minute workflow that fails after 5 minutes and then succeeds on a re-run, which comes to 15 billed minutes.
Storage pricing
GitHub measures storage every hour and bills the GB-hours accumulated over the month. Deleting artifacts stops further charges, but the hours already accrued stay on the bill. Artifacts are kept for 90 days unless you say otherwise, so a shorter retention-days on uploads that nobody opens after the run is the simplest saving.
The cache is counted separately. Each repository gets 10 GB, and GitHub evicts older entries when a repository reaches its limit. You're charged only if an administrator has raised the limit above 10 GB, and then for the usage above 10 GB, measured at each hour's peak.
Custom image storage has its own allowance: 75 GB on Team and 150 GB on Enterprise Cloud.
Self-hosted runner pricing
GitHub charges no Actions fee for jobs on self-hosted runners, in public or private repositories. It came close to changing that.
On December 16, 2025, GitHub announced two changes. Hosted-runner prices would drop on January 1, 2026, and from March 1, 2026 a $0.002 per minute "cloud platform charge" would apply to self-hosted runner usage in private repositories. The next day GitHub added an update saying it was "postponing the announced billing change for self-hosted GitHub Actions". The price cut went ahead as planned. As of October 2026, GitHub hasn't announced a new date.
Third-party runner pricing
Several companies run GitHub Actions jobs on their own machines. GitHub still schedules the workflow, and you pay the provider for the minutes instead. Our guide to GitHub Actions runners covers how hosted, self-hosted and third-party runners differ. These are list prices for each provider's 2 vCPU Linux runners and its smallest macOS and Windows runners.
Some of these don't reduce to one number. Namespace bills in unit-minutes: one unit is 1 vCPU with 2 GB of memory for a minute, at $0.001 on a prepaid plan or $0.0015 in overage, so a 2 vCPU runner with 4 GB counts as two units and one with 8 GB as four. Depot has no free tier: plans start at $20 a month for one user and $200 a month for a team. RunsOn isn't in the table because it's software you run in your own AWS account: you pay an annual license, from €300, and AWS bills you for the instances.
Free minutes are not plain minutes either. Blacksmith and Avrea both count them in 2 vCPU Linux x64 minutes, so other runners use them faster: Blacksmith's 3,000 are 1,500 minutes on Windows or 150 on macOS, and Avrea's are 1,500 on Windows, 1,000 on ARM or 150 on macOS.
Cache storage is priced by product, so the plans don't line up neatly. Avrea includes 25 GB per repository at no charge, shared across its GitHub Actions, Git LFS, build and package caches. Blacksmith's GitHub Actions cache also includes 25 GB per repository at no charge, and its Docker layer caching is an add-on at $0.50 per GB a month. Depot includes 25 GB of cache and registry storage with its $20 plan and 250 GB with its $200 plan, then charges $0.20 per GB a month. Namespace prices each cache separately: $0.20 per GB a month for its Turborepo, Gradle and Bazel caches and $0.0048 per GB a day for cache volumes plus $0.002 per GB-hour while a volume is attached, with allowances for both on its paid plans.
The machines behind these prices are not the same. Avrea's ARM and macOS runners are Apple M5 Max machines, and its ARM rate reflects that. A 2 vCPU runner at one provider can finish a build in half the time it takes at another, so the price of a minute tells you less than the price of a job. Our runner benchmark comparison shows how far apart they are.
Sources: the pricing pages and documentation of Blacksmith, Depot, Namespace and RunsOn, checked October 2, 2026.
When GitHub-hosted runners are the cheaper choice
If the repository is public, standard runners are free and there's nothing to save. If your private usage fits inside the included minutes, there's no bill to reduce either: 3,000 minutes covers 250 runs of the 12-minute workflow above.
A third-party runner starts to pay for itself when you're paying for overage every month, or when your jobs need larger runners, which never draw on the allowance. It can also make sense before either of those, if engineers waiting on CI costs you more than the minutes do.
How to lower your GitHub Actions bill
Find where the minutes go
The usage page under Billing and licensing in your GitHub settings breaks usage down by SKU and by repository. Look at it before changing anything. A bill that is mostly macOS minutes needs a different fix from one where a single repository runs a long test suite on every push. Once you know which workflows cost the most, our GitHub Actions observability guide covers how to find the slow steps inside them.
Combine very short jobs
Three 15-second checks cost 3 billed minutes as separate jobs and 1 minute as steps in a single job.
Test shards work the same way, as the example above showed. Add shards until the wait is acceptable and stop there.
Cut failed runs and retries
Put cheap checks in front of expensive ones. In the three-job workflow from earlier, adding needs: lint to the test and build jobs means a formatting error costs 1 billed minute, not 12. Tests start later on every run in exchange, so this pays off where lint failures are common.
A job that fails one run in ten for no reason costs about a tenth more, because every re-run is charged in full. When you do re-run, use "Re-run failed jobs", which re-runs the failed jobs and any jobs that depend on them, not the whole workflow.
Set timeout-minutes a little above each job's normal duration. Without it, a hung job runs for 360 minutes before GitHub cancels it, which on a 16-core Linux runner is about $15.
Leave fail-fast on in matrix builds. It is the default, and it cancels the rest of the matrix when one job fails. Setting it to false shows you every failure and bills you for every job.
Runs that a newer push has made irrelevant are the same kind of cost. concurrency with cancel-in-progress: true cancels them.
Use the cheapest runner that fits the job
Light jobs can run on the 1-core runner. ubuntu-slim costs $0.002 a minute, a third of the standard Linux rate. It runs in a container, has a 15-minute job limit and can't run Docker-in-Docker, so it suits labeling, triage and other short automation jobs, not builds.
Linux on arm64 is cheaper than Linux on x64. ubuntu-24.04-arm costs $0.005 a minute against $0.006, which is worth having for a workload that doesn't depend on the architecture, such as a Node or Python test suite with no native x64 dependencies.
Keep macOS and Windows for the jobs that need them. A macOS minute costs about ten times a Linux minute, so linting and platform-independent tests belong on Linux.
A larger runner pays off when it cuts the billed time by more than its higher rate, or when the job needs the extra memory or disk. The 8-core Linux runner costs 3.7 times the 2-core rate, so on compute alone a job has to finish more than 3.7 times faster to cost less.
What the same workflow costs on Avrea
The changes above remove minutes you didn't need. The minutes that remain are the builds and tests themselves, and their cost comes down to two numbers: how long the job runs and what the runner costs per minute. A different runner can change both.
Avrea is our runner service for GitHub Actions. Jobs run on Avrea's machines. You keep defining workflows and storing secrets in GitHub, and as on any runner, a job receives the secrets it references while it runs. You install the GitHub App and change the runner label, and the migration wizard can open that pull request for you:
Avrea's rates next to GitHub's
Sources: GitHub's Actions runner pricing reference and avrea.com/pricing, checked October 2, 2026.
From 2 vCPU up, Avrea's Linux x64 and Windows runners cost 20 to 33% less per minute than the GitHub runner of the same size. Avrea also bills each job for the seconds it ran, rounded down, with no minimum, where GitHub rounds each job up to a whole minute. The three-job workflow from earlier ran for 10 minutes 5 seconds and was billed as 12 minutes on GitHub, which is 7.2 cents. At the same durations on Avrea it costs about 4 cents.
There is no monthly fee. Each organization gets 3,000 free minutes a month on 2 vCPU Linux x64 runners, which other runner types use up at their own rates, and each repository gets 25 GB of cache storage.
Why jobs finish sooner on Avrea
Compiling, linking and running tests depend mostly on single-core speed and on how fast the runner reads and writes files. Avrea's runners are built around those two things, and around keeping caches close.
The Linux x64 and Windows runners use dedicated bare-metal AMD EPYC processors chosen for single-thread performance. In our Linux kernel benchmark, Avrea's 2 vCPU runner scored about 6,500 in single-core sysbench and GitHub's 2-core runner about 3,700.
The disks are local NVMe. On the same two runners, disk writes ran at about 4 GB/s on Avrea and about 220 MB/s on GitHub, which shows up in dependency installs, cache restores and any build that writes thousands of small files.
The caches run on the same infrastructure as the runners, so a restore reads from storage in the same datacenter instead of a remote storage service. actions/cache (v4 and later) and the setup actions work unchanged; in our cache benchmark, restoring a 1 GB cache took 14 seconds on GitHub and 2.9 seconds on Avrea. Package managers resolve through a local proxy, and build tools such as Go, Bazel and Gradle are preconfigured to use a remote build cache.
The kernel benchmark shows what that adds up to. The same build on the same 2 vCPU runner size took 27 minutes 23 seconds on GitHub and 9 minutes 3 seconds on Avrea with no cache, and 24 seconds with a warm ccache. At list prices that is 16.8 cents of runner time on GitHub, about 3.6 cents on Avrea, and about 0.2 cents with the cache. These are the build times the post reports, so treat the costs as estimates, not invoice lines.
Our case studies report what customers measured after moving their GitHub Actions jobs to Avrea. Teamspective's median CI run went from 10 minutes to 4.5. Luo's build stage went from 9 minutes 18 seconds to 3 minutes 5 seconds. PromoRepublic's went from about 4 minutes to 42 seconds.
Not every workflow speeds up. A build that spends most of its time waiting on an external service takes about as long on any runner. For caching on any runner, see A guide to GitHub Actions caching and How to speed up GitHub Actions.
macOS and ARM runners
On macOS, the 8 vCPU M5 Max runner costs $0.08 a minute. GitHub's standard runner, a 3 vCPU M1 on macos-26, costs $0.062, and its 5-core M2 Pro runner costs $0.102. In our iOS and macOS benchmark, with caches turned off, the M5 Max ran eleven builds of nine open-source apps 3.6 to 6.9 times faster than the standard runner and about twice as fast as the M2 Pro. The Firefox for iOS test build took 747.6 seconds on GitHub's standard runner and 139.6 seconds on Avrea. Prorated at list prices, that build step is about 77 cents on GitHub and 19 cents on Avrea. These are build-step times, not whole jobs, so an invoice would differ.
The ARM Linux runners use the same M5 Max chip, which has some of the fastest single-thread performance of any ARM processor. At 2 vCPU they cost $0.012 a minute against $0.005 for GitHub's ARM runner, so a job that finishes about 2.4 times faster costs roughly the same on both, before rounding and free minutes, and anything beyond that is a saving. The break-even is higher on larger sizes.
Try it on one workflow
Copy one workflow file, give it the Avrea label and push it on a branch. It runs next to your existing CI on the same commits, so you can compare job durations and cost directly. The console shows CPU and memory for each job, which also tells you whether the job needs the runner size it's on.
