What Are CI Minutes? How Billing Works
Last updated
CI minutes are the unit of compute time that continuous integration services bill for. In GitHub Actions, each job is billed for the minutes it holds a runner, rounded up per job, at a rate that depends on the runner type.
How it works
A job's billed time starts when a runner begins it and ends when the job finishes. GitHub rounds each job up to the next whole minute. A workflow with ten parallel 20-second jobs is billed ten minutes, not under four. Waiting in the queue is not billed, but waiting steps inside a running job are.
Rates depend on the runner. Standard Linux runners are cheapest. Windows and macOS have higher per-minute rates, and larger runners with more cores cost more per minute. Private repositories draw on a monthly allowance included in the plan, then pay for overage. Rates and allowances change, so check GitHub Actions pricing or GitHub's billing page.
Other vendors bill the same way with different rates, rounding rules and machine sizes. Compare them on runner pricing.
Worked example
Suppose a pipeline runs four jobs per push: lint (1 min), build (4 min), and two test shards (6 min each). That is 17 billed minutes per push. At 50 pushes a day across a team, that is 850 minutes a day, roughly 18,000 a month. Rough maths like this is what the GitHub Actions cost calculator automates.
Reducing CI minutes
on:
pull_request:
paths-ignore:
- "docs/**"
- "**.md"
concurrency:
group: ci-${{ github.event.pull_request.number }}
cancel-in-progress: true
jobs:
test:
runs-on: ubuntu-latest
timeout-minutes: 15
steps:
- uses: actions/checkout@v4
- Cancel superseded runs with a concurrency group.
- Skip work that cannot be affected, with
paths-ignoreor path filters. - Cache dependencies; see cache keys.
- Set
timeout-minutesso a hung job does not burn the default limit. - Fix flaky tests instead of rerunning them.
- Use faster machines: if a job finishes in half the time, a higher per-minute rate can still cost similar or less. See reduce your GitHub Actions bill.
compiler.dev runs the same jobs on an 8 vCPU Linux machine at $0.012 per minute, against $0.022 for GitHub's 8-core larger runner. Details on pricing.
Common mistakes
- Optimising minutes while ignoring wait time. Cheap and slow can cost more in developer time than fast and slightly pricier.
- Over-sharding. Each shard pays setup time, which is billed each time. See test sharding.
- Forgetting multipliers. A macOS minute does not cost the same as a Linux minute.
- Large matrix builds that multiply every run.
Related terms
FAQ
Are CI minutes the same as build minutes?
Yes. Vendors use both terms for billed compute time.
Do cancelled jobs count?
Time used before cancellation is billed.
Do self-hosted runners use CI minutes?
GitHub's rules for self-hosted runners have changed over time. Check GitHub's current billing docs. You pay for your own machines either way.
Related
- Job Exceeded Maximum Execution Time: timeout-minutesFix "The job running on runner has exceeded the maximum execution time of 360 minutes" in GitHub Actions. How timeout-minutes works for jobs and steps.
- What Is a Cache Key in GitHub Actions?A cache key is the string that identifies a saved cache in GitHub Actions. Learn how keys and restore-keys work and how to avoid stale caches.
- What Is a Concurrency Group in GitHub Actions?A concurrency group makes GitHub Actions run one workflow or job at a time per key and can cancel older runs. See the YAML and common mistakes.
- What Is a Flaky Test? Definition and CausesA flaky test passes and fails on the same code without any change. Learn the common causes, how to detect them in CI and how to fix or quarantine them.