GitHub Actions minutes cost: what CI/CD really costs you

Quick answer

GitHub Actions bills hosted runner usage per minute, with a monthly free allowance on private repos and unlimited free minutes on standard runners for public repos. The catch is the multipliers: Linux runners bill at the base rate, Windows runners at roughly 2x, and macOS runners at roughly 10x per minute. Larger runners with more vCPUs bill at higher per-minute rates too. On top of minutes you pay for Actions artifact and cache storage and, for GitHub-hosted larger runners, data. Minutes are rounded up per job, so many tiny jobs cost more than you expect.

GitHub Actions feels free until it is not. For public repositories and light private use it costs nothing, but as CI/CD grows, especially with matrix builds, macOS runners, or self-hosted infrastructure, the minutes add up. Understanding the per-minute model and its multipliers is how you keep CI from quietly becoming a meaningful line item.

How minutes are billed

Runner	Per-minute multiplier
Linux (standard)	Base rate (1x)
Windows	About 2x
macOS	About 10x
Larger runners (more vCPU)	Higher base per-minute rate

The base unit is a runner-minute on a standard Linux runner. Windows runners cost roughly twice as much per minute, and macOS runners roughly ten times as much, because Apple hardware is expensive to host. Larger runners with more vCPUs and memory bill at higher per-minute rates. Private repos get a monthly free minute allowance (varying by plan) and then bill per minute; public repos run standard runners free. Minutes are rounded up to the nearest minute per job.

Where Actions cost hides

The rounding matters: a workflow with many short jobs pays a full minute for each, so 50 ten-second jobs cost 50 minutes, not 8. Matrix builds multiply job counts fast. macOS jobs at the 10x multiplier dominate a bill even at low volume. And beyond minutes, Actions artifact and cache storage bills per GB-month, and larger GitHub-hosted runners can incur data charges, the kind of easy-to-miss extras that also show up in hidden cloud costs.

Cutting Actions minutes

Keep jobs on Linux runners wherever possible and reserve macOS only for genuinely Apple-specific builds. Cache dependencies to shorten build times, consolidate tiny jobs so per-job rounding hurts less, use path and branch filters so workflows do not run when irrelevant files change, and fail fast on matrix builds. For high, steady CI volume, self-hosted runners on your own compute can be cheaper per minute, though you then pay for and manage that EC2 capacity yourself and should consider spot to lower it.

Self-hosted versus GitHub-hosted

The build-versus-buy decision is a cost tradeoff. GitHub-hosted runners have zero maintenance and per-minute billing that is cheap at low volume but expensive at high volume. Self-hosted runners on your own instances (or an autoscaling pool) can be far cheaper per minute at scale, especially on spot capacity, but you own the provisioning, scaling, security, and idle cost. Model both against your actual CI minutes, and price the underlying compute for self-hosted runners against the resource catalog before switching.

FAQ

How does GitHub Actions bill for minutes?

It bills hosted runner usage per minute, rounded up per job to the nearest minute. Private repos get a monthly free minute allowance that varies by plan, then bill per minute; public repos run standard runners free. On top of minutes, you pay for Actions artifact and cache storage per GB-month and, for larger hosted runners, potential data charges.

Why are macOS GitHub Actions runners so expensive?

macOS runners bill at roughly a 10x per-minute multiplier over the base Linux rate because Apple hardware is expensive to host and license. Windows runners bill at roughly 2x. So even a small number of macOS build minutes can dominate an Actions bill. Reserve macOS runners for genuinely Apple-specific builds and keep everything else on Linux.

Why do many small Actions jobs cost so much?

Because minutes are rounded up to the nearest minute per job. A workflow with 50 ten-second jobs is billed 50 minutes, not the roughly 8 minutes of actual runtime. Matrix builds multiply job counts quickly, compounding the effect. Consolidating tiny jobs and limiting matrix dimensions reduces the rounding overhead.

How can I reduce GitHub Actions costs?

Keep jobs on Linux runners and reserve macOS for Apple-specific builds, cache dependencies to shorten runtime, consolidate tiny jobs to reduce per-job rounding, use path and branch filters so workflows skip irrelevant changes, and fail fast on matrix builds. For high steady volume, self-hosted runners on your own compute (ideally spot) can be cheaper per minute.

Are self-hosted runners cheaper than GitHub-hosted?

They can be at high, steady CI volume, especially on spot capacity, because you pay your own compute rate rather than the per-minute hosted rate. But you take on provisioning, autoscaling, security, and idle cost, and low-volume CI is usually cheaper and simpler on GitHub-hosted runners. Model both against your actual monthly minutes before switching.

Does C3X price CI/CD compute?

C3X prices the infrastructure in your Terraform, including the compute you would run self-hosted GitHub Actions runners on, against a live catalog before deploy. If you are weighing self-hosted runners, that lets you estimate the cost of the underlying instances (including spot) up front to compare against GitHub-hosted per-minute billing.

What to do next

Price self-hosted runner compute before you switch. C3X reads your Terraform and prices your resources against a live catalog. Start with the quickstart.