GitHub Actions matrix budget calculator

Count combinations before estimating time

A matrix dimension represents a set of distinct choices, such as three runtime targets or two operating-system targets. This tool accepts up to five axis sizes. Multiply those sizes to count the base combinations, because each choice on one axis is paired with every choice on the others. Set an unused axis to one; it then leaves the product unchanged. The inputs describe counts only. You do not need to paste code, name private projects, or upload a workflow to explore a scenario.

For a first estimate, write down what each axis means and whether its values are actually distinct. Two names for the same configuration should not silently become two different coverage requirements. Conversely, two targets that differ in a meaningful compatibility requirement should stay separate even if their execution times are similar. The arithmetic can reveal the work implied by a coverage decision, but it cannot decide which combinations the product must support. Keep that decision explicit when comparing alternative matrix sizes.

Base combinations = axis 1 × axis 2 × axis 3 × axis 4 × axis 5
Jobs = base combinations − distinct exclusions + additional unique combinations
Waves = ceil(jobs ÷ available workers)
Idealized elapsed minutes = waves × duration per job
Total job minutes = jobs × duration per job

Sources: GitHub Docs: Running variations of jobs in a workflow

Work through the default six-job scenario

The default axes contain three values, two values, and one value on each unused axis. That produces six base combinations. Excluding one known combination leaves five. Adding one genuinely new combination brings the scenario back to six jobs. With two available workers and a ten-minute duration for every job, the work takes three waves. Multiply three by ten for 30 idealized elapsed minutes. Multiply six by ten for 60 total job-minutes. These two time measures answer different questions.

Elapsed time describes how long this simplified batch takes to finish. Total job-minutes describes the aggregate execution across all jobs. Increasing the available workers from two to six changes the estimate to one ten-minute wave, but it leaves the aggregate work at 60 job-minutes. This does not imply a price or guarantee a faster real run. It isolates the consequence of the chosen worker count while holding job durations and every other assumption fixed.

A partly filled final wave still takes a full job duration. Five equal ten-minute jobs with two available workers need three waves: two jobs, two jobs, then one. The idealized elapsed time is 30 minutes and the aggregate execution is 50 job-minutes. If all base combinations are excluded and there are no additions, the scenario has zero jobs, zero waves, and zero execution time. That is a valid arithmetic result, not a statement that a particular empty workflow is valid.

Enter resolved exclusions and additions

The exclusions field counts distinct base combinations that you have determined should be removed. It does not count exclusion rules. In a hypothetical six-combination product, one rule might match two combinations; two overlapping rules might both match the same combination. Count the resolved unique removals in either case. The tool rejects a removal count larger than the current base product. Adding extra combinations cannot make that invalid removal count meaningful, so the validation checks exclusions before considering additions.

Similarly, the additional-combinations field counts new unique jobs after the exclusions have been applied. An edit to an existing combination does not necessarily add a job. GitHub’s matrix documentation explains that include entries can extend existing configurations or add configurations, while exclude entries remove matches. This calculator does not interpret those rules. Resolve the configuration set separately, inspect the actual workflow expansion, and enter counts that correspond to that result. Counting YAML list entries as jobs can give an incorrect budget.

Sources: GitHub Docs: Running variations of jobs in a workflow

Treat waves as an idealized capacity model

The available-workers input means the number of simultaneous job slots you assume the scenario can use throughout execution. GitHub’s max-parallel setting limits how many matrix jobs may run simultaneously; it does not establish that those slots will always be available. Account limits, eligible runner capacity, and competing work can affect the available concurrency. Choose a scenario value based on the capacity you want to examine, then compare it with observed execution before treating it as a useful estimate.

The wave calculation assumes equal job durations, immediate starts when slots become free, and no extra queue delay. A long-running job among otherwise short jobs can determine completion time in a way one common duration does not capture. Setup, downloads, and cleanup should be included in your duration input if you intend the result to represent the full execution of each job. Retries, cancellation, and changes in shared-resource performance remain outside the model. Use separate scenarios for materially different workloads rather than hiding those differences in one average.

Sources: GitHub Docs: Running variations of jobs in a workflow · GitHub Docs: Actions limits

A theoretical result is not a runnable matrix

GitHub’s Actions limits page currently specifies a maximum of 256 generated jobs for a job matrix per workflow run, applying to both GitHub-hosted and self-hosted runners. This calculator deliberately accepts larger arithmetic scenarios so their scale is visible. A result above that limit is not an executable single matrix. Check the current platform documentation before implementing a design, and do not treat an accepted numeric input as approval of a workflow configuration.

Even a result below 256 is not validation. The tool does not inspect expressions, dependencies, runner labels, permissions, artifacts, or the meaning of a configuration. Its own bounds keep the arithmetic finite: five axes of at most 100 values, up to one million additions, at most 256 assumed workers, and a maximum duration of 360 minutes per job. Those are modelling bounds, not a complete statement of GitHub’s platform limits or a promise that those resources are available to your account.

Sources: GitHub Docs: Actions limits

Use the estimate to review a concrete change

Before expanding a matrix, record the current axis meanings, the proposed new combinations, and the reason each addition is needed. Compare the two scenarios with the same duration and worker assumptions first, so the effect of the coverage change is visible. Then adjust those assumptions if you have evidence that the new jobs have different execution characteristics. A smaller matrix is not automatically better: removing a required compatibility check can make an attractive budget conceal a testing gap.

After implementing an independently reviewed workflow change, compare the planned job count with the resolved jobs and their execution records. Investigate differences in counts before interpreting time differences. For financial planning, the separate CI cost calculator accepts your applicable runner rate and extra execution ratio; this matrix tool reports unrounded execution minutes, not billable minutes. For agent-operated delivery, Agentic Pipeline’s public feature guide describes run controls and evidence that agents can inspect. Evaluate those capabilities against your actual delivery requirements; access remains closed beta, and this calculation makes no product performance or savings claim.

• Name the coverage requirement behind each axis and each additional combination.
• Count distinct removed combinations, including overlap between exclusion rules.
• Confirm runner eligibility and available concurrency separately from max-parallel.
• Compare resolved job counts and observed durations with the scenario.
• Keep execution-time estimates separate from billing and correctness decisions.

Sources: Agentic Pipeline: CI cost and rerun waste calculator · Agentic Pipeline: Public feature guide