GitHub Actions pricing, explained

Estimates use GitHub's published list rates and treat every minute as billed after rounding; storage and re-runs are extra on any provider.

• 01Public repositories run free on standard GitHub-hosted runners. Private repositories get an included-minutes allowance by plan, then bill per minute.
• 02The per-minute rate depends on the runner: Linux is the cheapest, Windows bills more, macOS bills roughly ten times the Linux rate, and larger runners are always billed, even on public repositories.
• 03GitHub rounds every job up to the next whole minute, so many short jobs, matrix legs, and re-runs bill more than the compute they use.
• 04The bill has two levers: bill fewer minutes (caching, path filters, cancelling superseded runs, timeouts), and pay less per minute (a drop-in runner label change).
• 05Want the audit done for you? Run the free /ci-speedup skill to find where your workflows waste billed minutes, then use this page to check its math.

Included minutes apply to private repositories running on standard GitHub-hosted runners; usage on standard runners in public repositories is free. The allowance resets monthly.

Once the included minutes are spent, each additional minute bills at a rate set by the runner's operating system and size. These are GitHub's published rates, checked 2026-09-28.

• Hosted runners got cheaper. On January 1, 2026, GitHub cut the price of GitHub-hosted runners by up to 39%, depending on the machine type. The rates above are the post-cut prices.
• The self-hosted runner charge was postponed. GitHub announced a $0.002-per-minute platform charge for self-hosted runners in private repositories, due March 1, 2026, then postponed it: "We're postponing the announced billing change for self-hosted GitHub Actions to take time to re-evaluate our approach." Self-hosted runners still bill no GitHub Actions minutes.
• Free allowances stayed the same. The included minutes in the table above still apply, and standard runners on public repositories stay free.

• GitHub · Actions runner pricing reference (per-minute rates by OS and size; minutes rounded up per job) (opens in new tab)
• GitHub · Actions billing concepts (included minutes by plan, what is free, storage accrual) (opens in new tab)
• GitHub · Changelog: 2026 GitHub Actions pricing changes (hosted-runner price cut; self-hosted charge postponed) (opens in new tab)
• StarSling · published runner pricing (opens in new tab)

• Every job is rounded up to the next whole minute. A 61-second job bills 2 minutes, and a matrix of twenty short jobs pays that rounding tax twenty times per run.
• Re-runs bill like first runs. A flaky suite that needs two attempts doubles that workflow's spend.
• Larger runners are never free and included minutes never apply to them, even on public repositories.
• Windows and macOS bill at higher rates than Linux, so a job that can run on Ubuntu should.
• Storage accrues hourly across the month. Deleting artifacts stops future accrual but does not remove charges already accrued.
• Superseded runs keep billing until they finish or are cancelled. Without a concurrency group, pushing a new commit leaves the old run burning billed minutes for a result nobody will read.

Have your agent check your GitHub Actions costs

Show me where my CI minutes and money go, across every runner provider I use, as a table ranked from most to least. Use the authenticated gh CLI. Read only: change nothing until I approve.

1. GitHub's bill. Get the owner from gh repo view --json owner (ask me only outside a repo or for an enterprise; query no other account). Select exactly one prefix: organizations/ORG, enterprises/ENTERPRISE, or users/USERNAME; then run gh api "/<selected-prefix>/settings/billing/usage?year=YYYY&month=M" for the last full month. From usageItems keep the Actions minutes and storage: netAmount (billed after included usage), quantity, unitType, by repositoryName and sku. On 403 or 404, re-run with gh api -i and give me the gh auth refresh -h github.com -s <scope> named in X-Accepted-OAuth-Scopes (fine-grained tokens need Administration (read) for an org or Plan (read) for a user; enterprises need a classic token).

2. Minutes on every runner, for the same month as the bill (created=YYYY-MM-01..YYYY-MM-DD on every runs call), in this order, within about 500 API calls in total. (a) Find the runners first: list the owner's repos (gh repo list OWNER --limit 1000 --json name,pushedAt), keep those with runs that month, and read their workflow files' runs-on labels. Map each label to a provider: GitHub-hosted (ubuntu-*, windows-*, macos-*, and larger runners matched to the bill's SKUs), StarSling (starsling-*), Blacksmith (blacksmith-*), Depot (depot-*), Namespace (namespace-profile-*), WarpBuild (warp-*), RunsOn (contains runs-on= or starts runs-on/), BuildJet (buildjet-*), otherwise self-hosted. (b) Sample next, up to about 250 calls, choosing sample sizes before the first call so the total fits: every workflow that ran gets at least one completed run from that month, then the busiest get up to about 10, each with its jobs (gh api "/repos/OWNER/REPO/actions/runs/RUN_ID/jobs?filter=all&per_page=100" --paginate). Bill each job as completed_at minus started_at, rounded up to the minute, confirm its provider from the job's labels, and record average billed minutes per run. (c) Count last, up to about 150 calls: one call per workflow (gh api "/repos/OWNER/REPO/actions/workflows/WORKFLOW_FILE/runs?created=RANGE&per_page=1" --jq .total_count). GitHub caps this count at 2,500; when it reads 2,500, do not split the range, estimate the month from the sample's runs per day instead. A workflow's monthly minutes are its run count times its average billed minutes per run, per runner. For GitHub-hosted runners the bill already has each repository's exact total: use these minutes only to split that total across the repository's workflows. If the budget runs out, still show every provider found, with what is known, marked as an estimate.

3. Prices. GitHub-hosted: the bill's netAmount is exact. StarSling: read https://starsling.dev/pricing.md, which maps each label to its price. Every other provider: estimate a range from GitHub's list rate for the same machine size, from half that rate to the full rate, using https://docs.github.com/api/article/body?pathname=/en/billing/reference/actions-runner-pricing, and label it an estimate. Self-hosted: minutes only, no price.

4. The answer. Start with a short summary: total CI spend and total runner minutes for the month, then one line per provider found (minutes and dollars, each marked exact or estimate; list only providers that ran jobs), then the share of the total that is exact. Anywhere in the answer, mention only providers that ran jobs, never ones that did not or that appear only in workflow files. Next, one table of the top 5 workflows ranked by runner minutes per month, highest first: repository, workflow, provider and runner, minutes per month, and dollars per month, with each figure marked exact or estimate. Put every other workflow in one row below them, with its count and totals. Exact: GitHub-hosted totals per repository and storage, both from the bill. Estimate: GitHub-hosted totals split across workflows, and all minutes and dollars on every other provider, because GitHub records those jobs but does not bill them (run counts are exact, run lengths are sampled). Add storage (artifacts and caches) from the bill as its own rows. Then the same totals by repository, and a line saying what share of the total is exact. Keep included minutes in mind: GitHub charges only for minutes above the plan's allowance, so one fix can remove more than its own row.

5. Then offer these drill-downs and wait for me to pick: (a) exact prices for my other providers, which you read from each vendor's live pricing page, (b) the jobs inside the workflows with the most minutes, (c) runs repeated on a commit that already passed, and the skip condition that let them through, (d) storage: the largest artifacts and which have no expiry, (e) the smallest set of workflow changes that removes the most spend, with dollars saved each, (f) what each row would cost on StarSling. Wait for my approval before editing anything.

• macOS or Windows SKUs near the top. macOS bills roughly ten times the Linux rate and Windows two-thirds more (rates above). Keep those jobs to builds that need that operating system, and path-filter the workflows so they run when their code changes.
• Larger-runner SKUs. Larger runners bill every minute, and included minutes never apply to them. Right-size each job to the smallest runner that keeps its wall-clock.
• A matrix workflow with a high total. Each leg bills as its own job and rounds up to the next whole minute, so twenty 30-second legs bill 20 minutes. Build only affected projects so a small change runs a small matrix.
• The same workflow billed many times per pull request. Superseded runs keep billing until cancelled, and re-runs bill like first runs. A concurrency group that cancels superseded runs stops paying for commits you have already pushed past.
• One job with a very long run time. GitHub lets a hung job run, and bill, for up to 6 hours; bound job timeouts cap it.

To have an agent run this audit on your repository, run the free /ci-speedup skill to find where your workflows waste billed minutes. For the Linux minutes that remain, StarSling runners are priced 21 to 33% below the GitHub-hosted equivalent at every size, and the switch is a one-line runner label change.

This prompt turns the rules above into an audit of your own repository: where the billed minutes go, how much is rounding and re-runs, and the smallest changes that cut the bill.

Audit this repository's GitHub Actions spend. Inspect .github/workflows/*.yml and .github/workflows/*.yaml, then report where billed minutes go: which workflows and jobs run most often, which runner operating systems and sizes they bill on, and how much of the spend is rounding (jobs that finish in seconds but bill a whole minute), re-runs, superseded runs, or jobs triggered by changes that cannot affect them. Propose the smallest set of changes that cuts billed minutes without changing product behavior: concurrency groups that cancel superseded runs, caches keyed on lockfiles, path filters, affected-only builds, job timeouts, and right-sized runners. Estimate the minutes each change saves, then open one small PR with the highest-impact fixes and before/after reasoning.

• Cancel superseded runs: a concurrency group keyed on the ref stops billing for commits you have already pushed past.
• Cache dependencies: a cache keyed on the lockfile stops every run re-downloading and rebuilding the same packages.
• Use path filters: docs-only changes should not bill an expensive test suite.
• Build only affected projects: a one-package change should not bill a full monorepo build.
• Bound job timeouts: GitHub otherwise lets a hung job run, and bill, for up to 6 hours.

StarSling's agents open these same fixes as reviewable AI optimization PRs, and every one of them can also be applied by hand; the best-practices catalog carries the YAML.

The other lever is the rate itself. StarSling's Linux runners are drop-in replacements priced 21 to 33% below the GitHub-hosted equivalent at every size. GitHub reference prices are GitHub's larger-runner list prices for Linux x64, checked 2026-09-28; StarSling rates are the published rate card.

Queue time is never billed on StarSling and there are no seat fees; new accounts get 2,000 free minutes in the first month. The migration is the one-line change below.

Keep GitHub Actions syntax, keep existing actions, and change the runner label on Ubuntu/Linux jobs to a supported StarSling instance type. StarSling runners are Linux only, so macOS and Windows jobs stay on GitHub-hosted runners.

runs-on: ubuntu-latest

runs-on: starsling-ubuntu-24.04

• Keep GitHub Actions syntax and existing actions.
• Change runner labels on Ubuntu/Linux jobs only.
• Lower per-minute rate at every size, and queue time is never billed.
• Checks, branch protections, and PR review flow stay in GitHub Actions.

• Your workflows already run on ubuntu-latest or ubuntu-24.04, where the migration is a one-line runs-on change.
• Paid Linux minutes dominate the bill, so a 21 to 33% lower per-minute rate compounds on every run.
• Billed minutes are inflated by cache misses, superseded runs, broad triggers, or runaway jobs, the waste AI optimization PRs turn into reviewable diffs.
• You want the bill to go down while GitHub Actions syntax, checks, and branch protections stay exactly as they are.

A bill dominated by macOS or Windows minutes will not move much on Linux runners: scope those jobs to what genuinely needs them, then move the Ubuntu jobs.

• Fast GitHub Actions
• GitHub Actions alternatives
• GitHub Actions CI best-practices catalog

• GitHub's rates and allowances quoted here are GitHub's published figures, checked 2026-09-28; GitHub's billing docs are the authoritative source.
• StarSling runners are Ubuntu/Linux only; macOS and Windows jobs stay on GitHub-hosted runners.
• StarSling keeps GitHub Actions syntax, checks, and branch protections. It is not a replacement CI platform.
• For new accounts, AI-powered optimization PRs are only available to customers on paid plans and are not enabled by default.

• Self-hosted GitHub Actions runners
• Fast GitHub Actions
• Diagnose why GitHub Actions is too slow
• GitHub Actions alternatives
• StarSling vs GitHub Actions
• GitHub Actions CI/CD pipeline
• GitHub Actions CI best practices
• Cancel superseded runs
• Cache dependencies
• Path-filter workflows
• Build only affected projects
• Bound job timeouts
• How Partcl cut GitHub Actions cost 13×
• How Mastra got 6× faster GitHub Actions tests
• How Better Auth got 2× faster E2E tests
• StarSling Runners are now generally available
• How to run automated code review in GitHub Actions
• Install the free /ci-speedup skill to fix slow GitHub Actions
• Install the free /ci-score skill to improve your GitHub Actions setup