Estimating GitHub Actions Minutes and Cost

Pull these from your repository's Actions usage and run history, not from guesses:

• Runs per month: count workflow runs by trigger. Pull requests, pushes to main, scheduled jobs and manual runs behave differently.
• Minutes per job: each job in a workflow is timed separately, and hosted-runner time is generally rounded up per job, so many tiny jobs cost more than they seem. Check current billing documentation.
• Jobs per run: matrix builds multiply jobs, for example three operating system targets times four language versions is twelve jobs.
• Runner type: Linux, Windows and macOS hosted minutes are billed at different rates, with larger runners costing more. Look up the current rates.
• Included minutes: your plan may include some minutes each month. Confirm the current amount for your plan.

Add up minutes per runner type, subtract the included amount where it applies, and multiply the remainder by each rate. Keep a separate line for storage of artifacts and caches.

Say your team opens 300 pull requests a month and each pull request triggers an average of 3 pushes. Each push runs a test workflow with 4 jobs of 6 minutes each on Linux. That's 300 × 3 × 4 × 6 = 21,600 minutes a month.

Now suppose each job's setup wastes 2 minutes installing dependencies because nothing is cached. That's 300 × 3 × 4 × 2 = 7,200 minutes of avoidable time, a third of the total. For illustration, suppose the placeholder rate is $0.01 per minute (a round number, not GitHub's actual rate). In this example the waste is $72 a month, and the whole workflow is $216. The exact dollars matter less than the shape: the multipliers stack, so trimming any one of them compounds. Speed also affects your pipeline's usefulness: DORA's 2024 report puts lead time for changes anywhere from under one day to one to six months across its clusters¹, and slow CI is a common contributor.

Apply these roughly in this order, since the first few pay off most:

1. Cancel superseded runs: use concurrency settings so a new push cancels the previous run for the same branch.
2. Cache dependencies and build outputs, keyed on lockfiles.
3. Use path filters so documentation-only changes don't run full test suites.
4. Trim matrices to what you actually support, and run the full matrix nightly instead of on every push.
5. Set job timeouts so a hung process doesn't burn an hour.
6. Run fast checks first and make slow ones depend on them, so cheap failures stop the pipeline early.
7. Reduce scheduled workflows that run more often than anyone reads their results.

Don't remove tests to save money if it means slower detection of real problems; the goal is to stop paying for waste, not for coverage.

Larger hosted runners cost more per minute but finish faster, so total cost can stay similar while developers wait less. Try them on your slowest workflow and compare cost and duration. Self-hosted runners charge no per-minute fee from GitHub but cost you the machines, maintenance, security hardening and scaling logic, and they require care with untrusted code from forks. The tradeoffs are covered in when self-hosted runners are worth it.

If you're choosing a CI system at all, read GitHub Actions vs GitLab CI vs CircleCI. Bills for CI are usually smaller than databases and identity, so compare with the managed Postgres cost calculator and the Auth0 pricing calculator before spending time here.

Compare your estimate to the actual usage report after a month and explain any gap. Common surprises are scheduled workflows nobody remembered, forks triggering runs, retried flaky jobs, and artifact storage that grows unbounded with long retention. Set a spending limit or alert in billing settings so a runaway workflow doesn't surprise you, and review the top workflows by minutes monthly. If security scanning is part of the pipeline, its minutes count too; see dependency vulnerability scanning on GitHub for what to include.