GitHub Actions is the default CI/CD choice for a lot of teams… right up until your monthly spend stops being “a rounding error” and starts showing up in budget reviews.
This guide breaks down how Actions is billed in 2026, what actually changed on January 1, 2026, and the practical levers that reduce spend without slowing delivery.
You’ll learn:
The official GitHub Actions per-minute rates (standard + larger runners)
How included minutes work (and where they don’t)
Real-world examples you can copy into a spreadsheet
A simple strategy to keep CI fast and predictable
What changed in 2026?
GitHub-hosted runner prices dropped (effective January 1, 2026)
GitHub reduced GitHub-hosted runner prices by up to 39% starting January 1, 2026. The GitHub Blog
Self-hosted “platform fee” was announced, then postponed
GitHub also announced a $0.002/min platform charge for self-hosted runners (originally described as starting March 1, 2026) — but later posted an update saying they’re postponing that billing change to re-evaluate their approach. The GitHub Blog
Current billing docs still describe GitHub Actions usage as free for self-hosted runners. GitHub Docs
The 60-second mental model: how billing works
Jobs run on runners (GitHub-hosted standard, GitHub-hosted larger, or self-hosted).
For GitHub-hosted usage in private/internal repos, you consume included minutes first, then pay per minute. GitHub Docs
GitHub rounds each job up to the nearest whole minute — small jobs can be disproportionately expensive if you have lots of them. GitHub Docs+1
Larger runners are always billed and can’t use included minutes. GitHub Docs+1
Official GitHub Actions runner pricing (USD per minute)
Standard GitHub-hosted runners (rate card)
Runner | SKU | Price / minute (USD) |
Linux 1-core | linux_slim | 0.002 |
Linux 2-core | linux | 0.006 |
Windows 2-core | windows | 0.010 |
macOS (3–4 core, M1/Intel) | macos | 0.062 |
Source: GitHub Actions runner pricing reference. GitHub Docs
Larger runners (x64) (examples people actually buy)
Runner | SKU | Price / minute (USD) |
Linux 4-core | linux_4_core | 0.012 |
Linux 8-core | linux_8_core | 0.022 |
Linux 16-core | linux_16_core | 0.042 |
Windows 4-core | windows_4_core | 0.022 |
Windows 8-core | windows_8_core | 0.042 |
Windows 16-core | windows_16_core | 0.082 |
macOS 12-core | macos_l | 0.077 |
Full x64/arm64/GPU tables are in the official doc. GitHub Docs
Runner specs (why “the same workflow” can cost more than you expect)
GitHub publishes different standard runner specs depending on whether the repo is public or private:
Private repos: ubuntu-latest is listed as 2 CPU / 7 GB RAM, and windows-latest as 2 CPU / 7 GB RAM. GitHub Docs
Public repos: ubuntu-latest and windows-latest are listed as 4 CPU / 16 GB RAM. GitHub Docs
ubuntu-slim (1 CPU) runs in a container and has a 15-minute job timeout (great for quick automation, not great for heavy builds). GitHub Docs
If your builds feel “randomly slower”, it’s often because you’ve unintentionally shifted work onto smaller runners, or you’re paying for concurrency instead of fixing the slow step.
Included minutes by plan (what’s “free” before billing starts)
Plan | Included minutes / month | Included artifact storage |
GitHub Free | 2,000 | 500 MB |
GitHub Pro | 3,000 | 1 GB |
GitHub Team | 3,000 | 2 GB |
GitHub Enterprise Cloud | 50,000 | 50 GB |
Included minutes reset each billing cycle. Larger runners are always charged. GitHub Docs
Cost examples (copy/paste math)
Formula:
monthly_cost ≈ max(0, minutes_used − included_minutes) × rate_per_minute
Example 1 — Small team on Linux 1-core
1,500 minutes/month on linux_slim ($0.002/min)
GitHub Free includes 2,000 minutes
Bill: $0 (covered by included minutes). GitHub Docs+1
Example 2 — Team plan, steady CI load
9,000 minutes/month on Linux 2-core (linux, $0.006/min)
GitHub Team includes 3,000 minutes
Billable minutes = 9,000 − 3,000 = 6,000
Bill: 6,000 × 0.006 = $36/month GitHub Docs
Example 3 — macOS is still the multiplier
3,000 minutes/month on macos ($0.062/min)
Bill (before included minutes): 3,000 × 0.062 = $186/month GitHub Docs
Why Actions spend “creeps” over time
This is what usually drives the graph up:
Workflow sprawl (lots of small jobs → rounding hurts)
Retried jobs (flake = double bill)
Over-parallelization (fast wall-clock, expensive minutes)
macOS-heavy pipelines (can dominate your bill fast)
Artifact/cache storage growth (quietly adds up alongside minutes)
Best practices to cut spend without slowing delivery
Use ubuntu-slim for lightweight automation, not builds (and remember the 15-minute limit).
Collapse tiny jobs where it makes sense (fewer job start-ups → less rounding waste).
Get ruthless about caching + artifacts retention (storage is real money).
Treat macOS minutes like a scarce resource: cache aggressively, avoid duplicate builds, only run where required.
Don’t “buy” a larger runner until you’ve proven the slow step is CPU-bound.
StackTrack GitHub Actions Build Service: predictable builds without always-on runners
A lot of teams end up in the same place: GitHub-hosted runners are simple, but you hit queues and the minutes add up. Self-hosted runners can reduce per-minute spend, but you inherit the operational tax (patching, capacity planning, noisy neighbors, networking, security reviews) — and GitHub has already signaled that self-hosted billing may change again after the postponed March 2026 update. GitHub+2
StackTrack’s GitHub Actions Build Service is built for the middle ground:
On-demand ephemeral agents (no idle fleets) StackTrack
Dedicated compute (build isolation / no noisy neighbors) StackTrack
Multi-platform: Linux, Windows, macOS; Intel + Arm; and support for VMs/containers/Kubernetes-style workflows StackTrack
Network connectivity options so agents can reach private environments (VPN/private networking) StackTrack
Transparent pricing + estimator so you can forecast spend by OS/architecture/size StackTrack
How it works (in practice): connect your GitHub org → use the right agent labels → point workflows at them and we automatically scale concurrency when CI load spikes. StackTrack
