← GitHub Actions Minutes Estimator
Your GitHub billing page is the only place that shows what you actually paid. It is authoritative, and nothing here replaces it as the number to reconcile against. What it does not do is attribute that number to a workflow, a job, or a matrix leg, and it cannot tell you anything about a workflow you have not merged yet -- it only reports minutes already spent, added up across the whole account.
This tool reads the workflow YAML you paste and runs the same billing arithmetic GitHub applies -- the OS multiplier, per-job rounding, the free plan's included minutes -- forward, before you merge, and attributes the projected cost per workflow and per job. It answers a different question than billing does: not "what did I spend" but "what is this about to cost."
| Question | Where to answer it |
|---|---|
| What did my account actually get charged last month? | Your GitHub billing page -- it is the source of truth for money that already moved. |
| What will this workflow I'm about to merge cost, before it runs once? | This estimator -- billing has no answer for a workflow that has not run yet. |
| Which job or matrix leg is actually spending my allowance? | This estimator -- billing reports one aggregated number for the whole account, not a breakdown per workflow or job. |
| I want this checked automatically before a change merges, failing the build if it pushes usage over budget. | This estimator's CLI -- node cli.mjs --max-allowance-percent 80 .github/workflows exits non-zero, wired into CI itself. |
In practice the two are used together: this tool before a change merges, to catch an expensive pattern while it is still a diff, and the billing page afterward, to confirm the account actually spent what was projected.
Paste the workflow file you are about to change and see the projected monthly cost, with the expensive patterns named, before it reaches your billing page at all.
Free, runs entirely in your browser, nothing is uploaded. Already out of minutes and staring at red checks instead? actions-runner-starvation-check tells you whether a red check is a real failure or a job GitHub never assigned a runner to.
No. The billing page is the only place that shows what you were actually charged, and it is the source of truth to reconcile against. This tool exists for the question the billing page cannot answer -- what a workflow you have not merged yet, or one you are changing right now, will cost -- so the two are complementary rather than substitutes.
You can, but by then the minutes are already spent, and the billing page still will not tell you which workflow or which job spent them -- it reports a single aggregated number for the account. Attributing that total back to a specific matrix leg or a specific cron schedule is arithmetic you would have to do by hand, from memory of what changed and when, on every workflow you suspect.
No, and that is most of what it replaces. The multipliers, the per-job rounding, and the free-minutes-only-on-public-repos rule are exactly the arithmetic this tool applies to your pasted YAML, so you do not have to re-derive them from GitHub's documentation each time you want an answer for a specific workflow. How GitHub Actions minutes are billed explains that arithmetic in full if you want to check the tool's working.
No. Parsing and costing happen entirely in your own browser and nothing is sent anywhere -- there is no server this portfolio operates that ever sees the YAML you paste. The CLI version reads local files and makes no network call at all, which is the same trust boundary as running grep on your own repository.