Retry tax

Retry tax is the recurring cost of re-running CI work that already ran: the compute minutes, queue time, and engineer attention consumed by retried jobs and pipelines. It is the price a team pays for treating "re-run until green" as a fix instead of a symptom.

How it is measured

A retry is a run attempt beyond the first for the same pipeline. The retry tax over a time window is:

• retried-run share — the percentage of runs that needed more than one attempt, and
• wasted minutes — the compute burned by every attempt beyond the first, since that compute bought no new information about the code. Providers do not keep per-attempt durations once a run is re-run, so this is an estimate: the last attempt's duration multiplied by the number of discarded attempts.

On GitHub Actions, retries are visible in run metadata (run_attempt greater than 1), so the tax can be computed from pipeline observability data alone — no code access, no build agent. GitLab CI works differently: retrying a pipeline re-runs its failed jobs inside the same pipeline — the pipeline id does not change — and superseded attempts are hidden from the jobs list unless include_retried=true is requested (GitLab API docs, as of 2026-07-28). There is no attempt counter on the pipeline record TrimCI syncs, so on GitLab the retry pattern shows up indirectly, as fail-then-pass alternation on the same branch.

Why it matters

Retry tax compounds quietly. A suite that "usually passes on the second try" doubles its own compute bill for every affected run, stretches the feedback loop developers wait on, and hides the flaky tests that cause it — because the final status reads green. The arithmetic is unforgiving: at a 15% retried-run share, assuming one retry each and comparable durations, roughly one CI minute in eight is spent re-running work that already ran — and none of it buys new information about the code.

A rising retry tax is one of the strongest signals that flaky behavior is being managed by habit instead of being fixed. The fix list starts with the pipelines whose retries cost the most minutes, not the ones that fail most often — a failure that retries in 40 seconds is cheaper than one that retries a 25-minute suite.

TrimCI's PDF reports carry a Re-run tax section for GitHub Actions: the share of runs that needed more than one attempt, how many of those went green on a later attempt with no new commit, an approximate count of the compute minutes the discarded attempts burned, and the repositories and pipelines with the most retries. GitLab runs are excluded from those figures for the reason above.