GitHub Actions billable minute

A GitHub Actions billable minute is one minute of GitHub-hosted runner time on a private repository, metered per job, rounded up to a whole minute, and charged to the repository owner at a rate that depends on the runner's operating system and size — after the account's monthly included minutes are used up.

How the meter works

Four rules do most of the work:

1. Metering is per job, not per workflow. Each job's duration is measured on its own.
2. Partial minutes round up. GitHub's runner pricing reference states that it rounds the minutes and partial minutes each job uses up to the nearest whole minute — so ten 10-second jobs bill ten minutes. See CI minute rounding.
3. The rate follows the runner. As of 2026-07-28 the published standard-runner rates are $0.006 per minute for Linux 2-core x64, $0.005 for Linux 2-core arm64, $0.002 for Linux 1-core, $0.010 for Windows 2-core, and $0.062 for macOS 3- or 4-core. By that rate card a macOS minute costs roughly ten times a standard Linux minute and a Windows minute about 1.7 times — the price gap explored in the macOS minute multiplier. Rates dropped by up to 39% on January 1, 2026, per GitHub's changelog.
4. Usage is charged to the repository owner, not to whoever pushed the commit that triggered the run.

What is free, and what is included

Standard GitHub-hosted runners are free on public repositories, and self-hosted runners are free — GitHub announced a per-minute platform charge for self-hosted usage and then postponed it, and as of 2026-07-28 GitHub's December 2025 changelog still records that postponement. Larger runners are the exception: GitHub charges for them even on public repositories.

Private repositories draw on a monthly quota that GitHub documents per plan: as of 2026-07-28, 2,000 minutes on Free, 3,000 on Pro and Team, and 50,000 on Enterprise Cloud, alongside separate artifact and cache storage allowances. Two caveats matter in practice: included minutes cannot be spent on larger runners, and because GitHub no longer publishes a numeric per-OS minute multiplier, treat Windows and macOS quota consumption as at least proportional to their higher list prices rather than as a documented fixed ratio.

Why it matters

The billable minute is not the wall-clock minute, and the gap is systematic rather than random. Per job rounding penalizes pipeline shape — matrix builds, sharded suites, per-package lint jobs — so a pipeline that looks efficient in the run view can bill well above its real compute. The operating system multiplies whatever waste exists. And the invoice itself totals by runner type and SKU, so no line item names the workflow that spent the minutes. GitHub does publish a breakdown elsewhere — as of 2026-07-28 organization-level Actions usage metrics split minutes by workflow, job, repository, runtime OS and runner type, with CSV export — but those figures are raw minutes with no per-OS multiplier applied, and they say nothing about which of those minutes went into failures and reruns.

That makes attribution the actual problem: not "how many minutes did we use" but "which repository, workflow and failure pattern spent them." The mechanics of what is metered are covered in GitHub Actions billing explained, and the reduction tactics in reducing GitHub Actions costs.

TrimCI estimates compute cost from synced pipeline-run durations at a per-minute rate you set per organization, ranked by repository and by failure cost. It reads pipeline metadata rather than your GitHub invoice, so treat its figures as an attribution model to hold next to the bill — not as a copy of it.