CI minute rounding

CI minute rounding is the billing rule that charges each CI job in whole minutes only, with every partial minute rounded up — which is why a 15-second job on a paid GitHub-hosted runner is billed exactly the same as a job that ran for 60 seconds.

How rounding works

GitHub's runner pricing reference states that the minutes and partial minutes each job uses are rounded up to the nearest whole minute. The operative word is job: rounding is applied per job, not per workflow. A workflow split into ten 10-second jobs consumes under two minutes of wall-clock compute but bills ten billable minutes. Rounding happens before the per-runner rate is applied — as of 2026-07-28, $0.006 per minute for standard 2-core Linux, $0.010 for standard 2-core Windows, and $0.062 for standard macOS, after the January 2026 price reduction; larger runners cost more — so a rounded-up partial minute costs the most where the macOS multiplier applies.

Same five minutes of compute, up to four times the bill. GitLab accounts for usage with a different model built on compute minutes, so the two providers are not directly comparable job for job.

Why it matters

Rounding overhead is a tax on pipeline shape, and modern pipeline design pushes teams straight into it: matrix builds, sharded test suites, per-package lint jobs, and fan-out/fan-in graphs all multiply the number of short jobs per run. The invoice reports minutes, not seconds, so the gap between compute you used and compute you paid for never appears on any provider surface — a pipeline of thirty 20-second jobs looks efficient in the UI while billing roughly three times its real usage on every single run.

The overhead also compounds with failure: every retried short job pays the round-up again. The usual mitigations — merging tiny jobs into steps of a larger job, trimming matrix dimensions that add no information — are covered in how to reduce GitHub Actions costs, and the mechanics of what gets billed at all are in GitHub Actions billing explained.

TrimCI estimates compute cost from synced pipeline-run durations at a per-minute rate you configure, so heavy repositories rank in dollars. It works at run granularity and does not model per-job round-up, so its estimate sits below what the provider bills — the gap between the two is roughly your rounding overhead.