How to estimate a monthly GitHub Actions bill from workflow run history
Your repository already holds what you need to forecast its Actions bill: a list of past workflow runs with the jobs in each and how long they took. This page turns that history into the four numbers the calculator asks for, then works one example through to a monthly figure.
Step 1: pick a representative period
Take the last four full weeks, or the last calendar month, of a period that looks like normal work. Note how many working days it had.
Step 2: count jobs, not runs
GitHub bills per job. One workflow run with a build job and a three-way test matrix is four jobs. The Actions tab of a repository lists each run, and opening a run shows its jobs with the duration of each. For more than a handful of runs, the GitHub CLI and the REST API return the same runs and jobs with their start and end times.
Leave out jobs that ran on self-hosted runners and, for a public repository, jobs on standard runners: GitHub's billing page states both are free. Count jobs that failed or were cancelled after they started; they used minutes.
Step 3: group by runner and note the durations
Each job's runs-on label tells you the runner: Linux, Windows or macOS, standard or larger. For each standard runner, write down the number of jobs. Then work out the average job length across all of them.
GitHub rounds each job up to a whole minute. If you have every job's duration, round each one up first and average the rounded figures; that is the number that matches the bill. If you only have an overall average, enter it as it is: the calculator rounds it up, which is an approximation.
Step 4: turn the counts into calculator inputs
- Jobs per day = jobs in the period ÷ working days in the period.
- Working days per month = the number you expect to bill, often 20 to 22.
- Average job length from step 3.
- Runner mix = each runner's share of the jobs, in percent.
Then choose the plan of the account that owns the repository. Included minutes belong to the account, not to one repository, so add up the jobs of every private repository the account owns.
Worked example
An organization on GitHub Team looks at four weeks, 20 working days, across its private repositories and finds 1,400 jobs: 1,120 on Linux 2-core, 210 on Windows 2-core and 70 on macOS. The jobs ran for 6,160 minutes in total, an average of 4.4 minutes.
The inputs are 70 jobs per day, 20 working days, 4.4 minutes, and a mix of 80% Linux, 15% Windows and 5% macOS. The calculator bills each job as 5 minutes, 7,000 minutes in all, against 3,000 included:
| Runner | Rate per minute | Minutes | Included minutes used | Minutes beyond the plan | Cost per month |
|---|---|---|---|---|---|
| Linux 2-core | $0.006 | 5,600 | 2,400 | 3,200 | $19.20 |
| Windows 2-core | $0.01 | 1,050 | 450 | 600 | $6.00 |
| macOS | $0.062 | 350 | 150 | 200 | $12.40 |
| Total | 7,000 | 3,000 | 4,000 | $37.60 |
The estimate is $37.60 a month, $451.20 a year. It shares the included minutes between the runners in proportion to their use. Included minutes are really used up in the order jobs run during the month, so the calculator also gives a range: $24.00 if the dearest runners happened to use the allowance, $47.80 if the cheapest did.
Check the estimate against the real bill
If the account has already been billed for a month, compare the estimate with the metered Actions usage shown in the billing section of the account's settings. When the two differ, the usual causes are:
- Rounding. The estimate rounds the average job up, which can land above or below the sum of individually rounded jobs.
- Larger runners. Their minutes are billed in full and never use included minutes. Price them separately; the calculator's full version does.
- Storage. Artifacts and caches beyond the plan's allowance are billed per GB per month, on top of minutes. The free estimate covers minutes only.
Enter your four numbers. The free calculator takes the plan, jobs per day, average job length and runner mix from your history and returns the same breakdown, in your browser.