A team opens its first serious GitHub Actions bill and cannot explain the shape of it. The per-minute rate looks trivial, a fraction of a penny for a Linux runner, so nobody has been watching. Yet the invoice is larger than the arithmetic suggests, and no single line explains why. The answer is that the number you get billed for is not the per-minute rate. It is that rate multiplied by which operating system you chose, against an allowance that resets monthly, with storage accruing quietly on the side.
GitHub Actions cost is shaped by four things most teams misread: what is actually free, how the included minutes work, the operating-system multiplier, and storage. Get those right and the compute bill stops surprising you. Then comes the part the invoice never shows: compute is the cheap half of CI/CD cost, and developer wait time is the expensive one. This is the GitHub-specific cut of the true cost of CI/CD.
What GitHub Actions actually bills you for
On GitHub-hosted runners you are billed for compute minutes, metered per minute of job execution, plus storage. Every plan includes a monthly allowance of minutes for private repositories: GitHub's billing documentation puts it at 2,000 minutes a month on Free, 3,000 on Team, and 50,000 on Enterprise Cloud. The allowance resets each month and does not roll over. Once you cross it, every further minute is billed at the runner's per-minute rate.
Two things are genuinely free and often forgotten. Standard GitHub-hosted runners are free for public repositories, so an open-source project on standard runners pays nothing for compute. Self-hosted runners are also free from GitHub's side, because you are already paying for the hardware they run on. The free path for a private, cost-sensitive workload is therefore either a public repository or your own runners, and the choice between them is about security and maintenance, not about the GitHub bill.
The multiplier that quietly inflates the bill
The per-minute rate is not one number. On standard runners GitHub bills a 2-core Linux runner at $0.006 per minute, a 2-core Windows runner at $0.010, and a 3-core or 4-core macOS runner at $0.062. Windows costs roughly 1.7 times the Linux rate; macOS costs roughly ten times it. The same job that costs a Linux runner one unit of compute costs a macOS runner about ten, for identical wall-clock time.
This is the single largest compute lever on most GitHub Actions bills, and it hides inside build matrices. A team building an iOS app runs on macOS because it has to, and that is unavoidable. But a matrix that fans a test suite across Linux, Windows, and macOS out of habit, when only Linux coverage was actually needed, pays the macOS premium on every run for no return. The included-minute allowance drains at the multiplied rate too: a macOS minute counts as ten against the allowance, so a mostly-macOS workload exhausts a Team plan's 3,000 minutes far faster than the raw job count implies.
The free-tier quirks that catch teams out
Most surprise bills trace to one of a handful of quirks. The public-versus-private split is the biggest: moving a repository from public to private turns previously free compute into metered compute overnight, which catches teams that open-source a component and later pull it back in. The allowance applies per account, not per repository, so one runaway repository can consume the whole organisation's minutes and leave the rest metered. And because the allowance is spent in multiplied minutes, teams that reason about it in raw job counts consistently underestimate how quickly a Windows or macOS workload burns through it. None of this is hidden, but all of it is easy to miss until the overage lands.
Storage is the line item nobody watches
Compute is not the whole bill. GitHub charges for the storage that pipelines produce: build artefacts and packages at $0.25 per gigabyte-month, and the Actions cache at $0.07 per gigabyte-month, accrued hourly beyond the included allowance. Artefact retention defaults are generous, so a workflow that uploads a large build output on every run, kept for the default retention window, can accumulate a storage bill that rivals its compute cost. Tightening retention and pruning stale caches is the cheapest optimisation on this list, and the one most often skipped because storage never shows up in a per-run cost estimate.
Compute is the cheap half
Every optimisation above is worth doing, and together they will not touch the largest cost in your pipeline. Compute is metered in cents per minute; developer wait time is metered in dollars per minute, because it is paid out of salaries while someone is blocked on a build. Across the CI/CD cost ledger, wait time usually dominates compute by roughly two orders of magnitude. A GitHub Actions bill you can finally explain is still the small number.
The connection runs both ways, which is why the compute optimisations still matter. A slow Windows or macOS job is not just ten times the compute cost; it is ten times the runner that a developer waits on before they can merge. Reruns driven by flaky tests double both halves of the bill at once. The cost per build formula and the developer wait time it produces are where the GitHub Actions invoice turns into the real number.
How CI/CD Watch surfaces GitHub Actions cost
CI/CD Watch, a CI/CD observability platform that monitors pipelines across GitHub Actions, GitLab CI, Bitbucket Pipelines, CircleCI, Azure DevOps, and Jenkins, reads your run history and estimates the compute cost of each run, repository, and organisation using the per-minute rates and the operating-system multiplier, then puts the developer wait time next to it. The two sit side by side so the macOS matrix that dominates the bill and the slow job that blocks merges show up as the same finding rather than two separate investigations.
The point is not the estimate itself; it is the decision it prompts. A cost breakdown that shows which repositories drive the compute bill, and which jobs drive the wait, is a list of candidates for rightsizing the runner OS, tightening retention, or fixing the flaky test behind the reruns. The Free tier covers pipeline-run monitoring across all six supported providers; the cost estimation and wait-time analysis sit on the paid tiers.
See what your GitHub Actions pipelines cost
If your GitHub Actions bill is larger than the per-minute rate led you to expect, connect your repositories and CI/CD Watch breaks the compute cost down by repository and runner OS, with developer wait time alongside it. The Free tier covers pipeline monitoring; the cost analysis layers on from the paid tiers. For the full ledger these numbers sit inside, the true cost of CI/CD overview covers compute, wait time, and the waste categories on both sides.
CI/CD Watch is built by 3CS Technologies Ltd. It started as an internal tool for tracking pipeline health across a mixed GitHub Actions and Jenkins estate. The same engine now powers the SaaS platform.