Work out what GitHub Actions actually costs: the platform multiplier that makes a macOS minute ten Linux minutes, the per-job rounding that bills a twenty second job as one minute, and where that lands against your included allowance.
Worked setups you can load into the form above. Each one is a decision the generator makes differently, and the reason it makes it.
The same work as the Linux run, at ten times the charged minutes. The multiplier applies to the included allowance as well as the price, so it is not a rate that softens at volume.
Rounding is per job, so twenty second jobs each bill a full minute. The same work in one job would bill a fraction of this.
A modest Linux workload on Team. Adding one Windows leg would double these minutes and one macOS leg would multiply them by ten.
Standard runners cost nothing on a public repository, whatever the platform. Larger runners are billed even there and draw on no allowance.
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
Minutes are multiplied by platform: Linux 1, Windows 2, macOS 10. A three-platform matrix is thirteen times a Linux run, not three, and the multiplier applies to the included allowance as well as the price.
Instead:Run linting, unit tests and builds on Linux, and reserve the other platforms for what genuinely needs them.
Billing rounds UP per job. Ten twenty-second jobs bill as ten minutes where the same work in one job bills as four.
Instead:Split for wall-clock time when the pieces are minutes long. Below a minute each, splitting costs money and saves nothing.
The cheapest minutes are the ones that never run. Superseded pushes, pull requests running twice because `push` has no branch filter, and hung jobs billing the full six hours usually outweigh any runner change.
Instead:Add a `concurrency` group, filter the `push` trigger to the branches you merge into, and set `timeout-minutes`.
They do not. Larger runners are billed from the first minute, on public repositories as well as private ones, and standard runners are free on public repositories entirely.
Instead:Check which runner class a job uses before reading any allowance figure.
Every number here multiplies, so an error in the run count is an error in the answer of the same proportion.
Instead:Take runs, jobs and minutes from the Actions usage report rather than from memory.
Two rules decide the Actions bill and neither is visible in the workflow file: minutes are multiplied by platform, and they are rounded up per job.
The multiplier applies to the included allowance and to the per-minute price, so it is not a headline rate that softens at volume. A matrix across Linux, Windows and macOS is not three times a Linux run, it is thirteen: one plus two plus ten. That single fact usually explains a bill nobody can account for.
same 4 minute job, per run:
ubuntu-latest 4 charged minutes
windows-latest 8
macos-latest 40
all three 52A job that takes twenty seconds bills as one minute. So ten small parallel jobs bill as ten minutes while the same work in one job bills as four. Splitting a job to parallelise it is worth doing when it saves wall-clock time and costs money when each piece lands under a minute.
Standard runners cost nothing on a public repository. Larger runners are billed everywhere, including on public repositories, and they do not draw on any included allowance at all: they are always on the invoice.
Three settings usually recover more than any runner change. A concurrency group cancels superseded runs on the same branch. A branch filter on the push trigger stops every pull request running the whole workflow twice, once for push and once for pull_request. And a timeout-minutes stops a hung job billing the full six hour default.
It multiplies the numbers you give it. It has no access to your usage, so the runs, jobs and minutes are yours to supply, and the accuracy of the answer is entirely the accuracy of those three figures: take them from the Actions usage report rather than estimating. The rate table was checked on 2026-08-17 and is a dated snapshot, not a feed, which is why there is an override field for the number on your own invoice. Larger runners, self-hosted runners, storage and data transfer are not modelled.