CI cost and rerun waste calculator

What this calculator measures

The useful question here is narrow: how much execution cost is associated with jobs that run again? Start with one monthly workload and one runner rate. The calculator assigns a cost to its initial job executions, then applies an extra execution ratio to that amount. Keeping those two numbers visible helps a team distinguish a larger workload from repeated work. The combined result is a scenario estimate for execution alone. Use GitHub’s billing guidance and official pricing calculator when you need a broader account estimate.

An initial run is the first attempt at a workflow in your chosen period. Jobs per run describes how many comparable jobs that first attempt starts. Average duration belongs to each job, not the elapsed time of the entire workflow. Two jobs running at the same time still represent two job executions in this model. Choose a group with similar duration and the same applicable runner rate; otherwise, a single average can hide the work responsible for the expense.

Initial cost = initial runs × jobs per run × rounded-up job minutes × USD per minute
Extra cost = initial cost × extra execution ratio
Combined cost = initial cost + extra cost

Sources: GitHub Docs: GitHub Actions billing · GitHub Docs: Actions runner pricing

A worked example, with per-job rounding

The starting example uses 1,000 initial runs, two jobs per run, five minutes per job, a hypothetical rate of $0.01 per minute, and an extra execution ratio of 0.2. Initial work contains 2,000 job executions and 10,000 rounded job minutes. That produces $100 of initial execution cost. Four hundred extra job executions at the same duration and rate add $20, so the combined execution estimate is $120. The rate is an illustrative input, not a statement of GitHub’s current price.

GitHub’s runner pricing documentation specifies rounding each job’s partial minute upward. Change the example duration from 5 to 5.1 minutes and each of the two jobs becomes six rounded minutes. Each initial run therefore accounts for twelve minutes, rather than rounding the combined 10.2 minutes to eleven. The example becomes $120 for initial work, $24 for extra work, and $144 combined. This tool assumes every job has the entered duration. Where individual durations differ, rounding their average is only an approximation; calculate separate groups or sum the actual rounded job durations.

Sources: GitHub Docs: Actions runner pricing

Measure extra executions, not rerun probability

The extra execution ratio is the number of additional job executions divided by the number of initial job executions. In the starting example, 400 divided by 2,000 equals 0.2, or 20%. It does not mean that every workflow has a 20% chance of being rerun. A workflow can repeat one failed job, several jobs, or all its jobs. Counting only workflows with a rerun would lose that distinction and can understate or overstate the amount of repeated execution.

Use attempts from a defined observation period and count each additional execution once. Keep the same repository, workflow, runner group, and time window in the numerator and denominator. A second extra attempt counts again. The ratio may exceed one: 3,000 extra executions against 2,000 initial executions gives 1.5, or 150%. The tool accepts ratios up to ten for bounded scenario exploration. When there are no initial executions, the observed ratio is undefined; entering zero runs simply produces a zero-work scenario, not a measured rate.

Label the reason for repeated work before calling it waste. A deliberate diagnostic rerun may be useful evidence. A flaky test, an unavailable dependency, and a cancelled run represent different causes and require different responses. The displayed extra cost is the estimated execution associated with repetition; it is not a promise that all of it can be removed. Review the underlying attempts before estimating avoidable cost or deciding which failure to fix first.

Sources: GitHub Docs: Re-running workflows and jobs

Collect these inputs from your own workload

Choose a complete month or another clearly labelled period before gathering numbers. Record the runner category, initial attempts, jobs in those attempts, individual job durations, and extra job executions. Match the entered rate to the runner category you actually use by consulting current documentation and your account’s usage information. Keep a note of the source and date alongside your calculation. A plausible number from a different runner or period can make a tidy estimate answer the wrong question.

If your workload mixes very short checks and long integration jobs, evaluate them as separate groups and record the results together. Do the same for jobs priced at different rates. Compare the resulting estimate with recorded usage to understand the gap before changing configuration. An average duration cannot describe every individual job, and an average jobs-per-run value may disguise conditional jobs. This tool requires a whole job count, so split variable workflows into representative groups instead of silently rounding their composition.

• Choose the period, repositories, workflow, and runner group.
• Count first-attempt job executions and extra executions separately.
• Inspect individual durations and split unlike jobs into separate scenarios.
• Check the applicable USD-per-minute rate and record when you checked it.
• Compare the scenario with your usage records and explain discrepancies.

Sources: GitHub Docs: GitHub Actions billing · GitHub Docs: Actions runner pricing · GitHub Docs: Re-running workflows and jobs

Read the estimate within its limits

The calculation does not apply plan allowances, repository eligibility rules, storage charges, taxes, credits, or operating-system multipliers. Enter the rate applicable to the jobs being modelled; the calculator will not select a runner or plan for you. A zero rate or zero workload is valid and gives zero execution cost within this scenario. It does not establish that the whole account is free. GitHub’s current billing documentation remains the source for how account usage becomes a bill.

The model also assumes extra executions take the same time as initial ones. If retries fail earlier, finish later, or use a different runner, measure them separately rather than treating this estimate as exact. Currency display rounds to cents for readability, while the calculation retains its numerical precision. Inputs remain on the page; copying a link includes the entered numbers in that link, and exporting saves a local JSON record. Check those numbers before sharing a scenario with someone else.

Sources: GitHub Docs: GitHub Actions billing

Use the result to choose a concrete next step

A useful outcome is a specific investigation, such as examining the integration job that accounts for most repeated minutes. Change one cause and compare equivalent periods, while retaining the verification the project requires. Do not turn the extra execution estimate directly into a savings forecast: workload changes, differing durations, and necessary diagnostics can all affect the comparison. Execution cost also excludes the time an engineer or agent spends diagnosing a failure, so keep those observations separate from the machine-cost estimate.

For teams considering a broader delivery change, Agentic Pipeline coordinates testing and deployment with evidence that coding agents can inspect. Its default Auto Profile path works without a repository recipe file; an existing consumer recipe takes precedence. That operating model is a separate evaluation from this calculator’s arithmetic. Review the public feature guide against an actual repository and the delivery task you need to improve. Access is currently closed beta, and this page makes no claim of a lower price, faster run, or guaranteed reduction in reruns.

Sources: Agentic Pipeline: Public feature guide · Agentic Pipeline: Choosing a GitHub Actions alternative