1. Paste your workflow files
One file, or several separated by a line of ---. Everything in .github/workflows/ is the useful answer; a single file tells you about that file.
2. Set your assumptions
These drive every number. Scheduled runs are counted exactly from each cron expression; everything else depends on how busy your repository is, which only you know.
Projected monthly cost
Where it goes
| Workflow | Job | Runner | Runs/mo | Jobs | Allowance min |
|---|
Findings
Assumptions behind these numbers
Run it in your own CI
The same estimator is a zero-dependency Node CLI. Wired into a workflow with a budget, it fails the build when a change pushes projected usage past a share of your allowance — which is the only moment anyone finds out before the minutes are gone.
node cli.mjs .github/workflows node cli.mjs --plan free --minutes-per-job 8 .github/workflows node cli.mjs --json .github/workflows # machine-readable node cli.mjs --max-allowance-percent 80 .github/workflows # exit 1 when over
Download cli.mjs, estimate.mjs and workflow-yaml.mjs and keep them next to each other. Node 18+, nothing to install, no network access required or used.
How the billing actually works
The multipliers and the per-job rounding are where most of the surprise lives. How GitHub Actions minutes are billed explains the arithmetic this tool uses and why a wide matrix of short jobs can bill several times its wall-clock time.
Already out of minutes and staring at a wall of red checks? actions-runner-starvation-check tells you whether a red check is a real failure or a job GitHub never assigned a runner to — the thing that happens after the allowance is spent.
Comparing CI vendors rather than estimating one workflow? Price GitHub Actions, CircleCI, GitLab, Bitbucket and Buildkite side by side at your build-minute volume.
Already reading your GitHub billing page and wondering what this adds? See this estimator vs. your billing page.
Think eyeballing the workflow file and doing the multiplication yourself gets you close enough? See this estimator vs. doing the math yourself for the three rules that go wrong by hand.
Questions
Why can't I just read my GitHub billing page?
Billing shows minutes you have already spent, aggregated across the account. It does not attribute them to a workflow or a job, and it cannot tell you what a workflow you are about to merge will cost. This reads the workflow files and does the arithmetic forward, so the answer arrives before the allowance does.
How are GitHub Actions minutes billed?
On private repositories, each plan includes a monthly allowance of minutes. Standard runners consume that allowance at a multiplier by operating system: Linux 1x, Windows 2x, macOS 10x. Each job's duration is rounded up to the next whole minute independently, so a wide matrix of very short jobs bills far more than its wall-clock time. Public repositories run free on standard runners.
What is the most common avoidable cost?
A workflow that triggers on both push and pull_request with no branches filter on push. A commit pushed to a branch with an open pull request fires both events, so the whole workflow runs twice on the same commit. Both runs are real, so nothing in the billing page marks one of them as waste.
Is my workflow file uploaded anywhere?
No. The page parses and costs everything in your own browser and sends nothing anywhere. There is no account and no analytics vendor. The CLI reads local files and makes no network call at all.
Are the dollar figures exact?
No, and they are not meant to be. They are an estimate built from your workflow files plus assumptions you set — how long a job takes, how often you push. Every assumption is shown on screen and is editable, and the published list rates being quoted are dated. Check the result against your own billing page before making a decision on it.