How Do I Estimate My GitHub Actions Bill?

Estimate a GitHub Actions bill by multiplying the billed minutes on each runner label by the per-minute rate for that label, then summing the labels and adding the usage add-ons that sit next to runner minutes. Pull the minutes term from the jobs report rather than from a guess, because the rates are fixed and published while the minutes are the only part of the estimate that can be wrong.

Answer

The formula is one line per runner label:

monthly cost = sum over labels of (runs per month x billed minutes per run x rate per minute)

Three inputs feed it. Runs per month and billed minutes per run come from your own history. The rate comes from the pricing page and the cloud runners documentation. Nothing else enters the formula: pricing is purely usage based, and there is no base subscription fee, no platform fee, and no seat fee, so the estimate has no fixed term to carry.

These are the rates for the labels used in the worked estimate below.

Rates checked on 2026-08-13 against the pricing page.

Detail

Step 1: pull real minutes per label

The Billing section of Reports has a CI tab where every row is a single job execution carrying repository, job name, runner label, stack, snapshot usage, execution time, billed time, and the cost split between runner and snapshot. The daily chart above the table stacks cost by repository or by runner label, which is the fastest way to see which labels are worth modelling and which round to nothing.

The Jobs section aggregates the same history per unique repository, workflow, and job name, with run count, success rate, duration at the 75th and 90th percentile, and queue time at the same percentiles. That is the table to estimate from, since it gives you both terms of the multiplication in one row.

Every tab exports to CSV, and the export contains all rows matching the current filters and sort order rather than the current page. Filter to a single month, export the Jobs table, and the estimate becomes a spreadsheet with one row per job.

If you have no history on WarpBuild yet, count the workflow runs of each job over the last 30 days in the GitHub Actions UI and use the durations shown there. Job durations move by a few percent when the same job changes machines, and job counts do not move at all, so a first estimate built from GitHub run counts lands close.

Step 2: write the assumptions down

An estimate that hides its assumptions cannot be argued with or corrected. State three numbers per job: runs per month, billed minutes per run, and the label the job uses. The assumptions below describe a team merging roughly 200 pull requests a month, with three Linux jobs on every pull request, an iOS build gated to changes under ios/, and a Windows test job on a subset.

Step 3: run the arithmetic

Add the usage items that bill alongside runner minutes, priced on the pricing page: at 40 GB-month of cache storage the cache line is $8.00 at $0.20 per GB-month, and 150,000 cache reads and writes add $15.00 at $0.0001 per operation. The estimate lands at $344.28 for the month. Signup includes $10 free credits, so the first invoice on that usage is $334.28.

Two rows carry most of the total. Integration shards are 800 job executions rather than 200, because a 4-way matrix multiplies the run count, and macOS bills $0.08 per minute against $0.004 per minute for the 2 vCPU Linux x64 label. Estimates that miss by a wide margin usually miss on one of those two mechanics.

Step 4: check the estimate against per-minute rounding

Billing is per minute, so a job that finishes in 35 seconds bills a full minute. That gives the estimate a floor: billed minutes for a label are never lower than the number of job executions on it. A 20-way lint matrix where each shard finishes in 40 seconds bills 20 minutes, while the estimate built from a 40 second average would predict 14. Fleets with thousands of short jobs should model job count first and duration second.

The reverse check matters too. Billed time and execution time are separate columns in the Billing table, so comparing the two on a sample of rows tells you how much rounding your fleet actually absorbs before you extrapolate a year from it.

Step 5: price the same minutes at GitHub list prices

Once the minutes are real, they can be priced twice. The 3,600 unit test minutes above cost $28.80 on WarpBuild: warp-ubuntu-latest-x64-4x (4 vCPU, 16 GB) costs $0.008 per minute against $0.012 per minute for the 4-core Linux larger runner (4 vCPU, 16 GB), which is 33 percent lower list price, with the GitHub list price checked on 2026-08-13 at docs.github.com. The same 3,600 minutes at $0.012 come to $43.20.

Every cost figure on this page carries a number, a source, and a checked-on date, and holding your own estimate to that standard is what makes it reviewable by someone who did not build it.

Step 6: re-run the estimate monthly

Export the Jobs table on the same date each month and compare the previous estimate against the actual invoice line per label. Drift almost always comes from run count rather than duration, since matrices grow and path filters loosen faster than test suites slow down. The minutes budget guide turns the estimate into a budget with per-label ceilings, and the cost reduction guide works through the levers that move each row.

Related Questions

What minutes number should I use in the estimate?

Use billed minutes per runner label. The Billing section of Reports shows billed time and execution time on every job row, and the Jobs section gives run count with duration at the 75th and 90th percentile per repository, workflow, and job name. Multiply run count by P75 for a working estimate and by P90 for the pessimistic one.

Does the estimate change when we add engineers?

Only through the extra workflow runs those engineers trigger. The formula has no seat term and no account term, so growing from 40 to 60 engineers moves the estimate through job count and job duration alone. Every rate that feeds it is on the pricing page.

How do I check my estimate against GitHub-hosted list prices?

Price the same minutes twice. warp-ubuntu-latest-x64-4x (4 vCPU, 16 GB) costs $0.008 per minute against $0.012 per minute for the 4-core Linux larger runner (4 vCPU, 16 GB), which is 33 percent lower list price, with the GitHub list price checked on 2026-08-13 at docs.github.com. Apply both rates to your minutes per label and compare the two totals.