What failed builds really cost

The real cost of a failed build is dominated by people, not machines. A defensible estimate prices four things: the engineer minutes spent diagnosing the failure at a fully loaded rate, the context-switch tax of being pulled off other work, the compute burned by the failed run and its retry, and a queue-wait multiplier for the time the verdict spends waiting for a runner. On standard Linux runners the compute inside a typical failed run costs well under a dollar; the interrupted engineer costs tens of dollars. Multiplied over a month, a mid-size team is losing thousands — almost none of it visible on any bill.

This article builds the model step by step: the formula, honest defaults for every input, worked examples at three team sizes, and how to present the result to management without overselling it. The output is an estimate, not an invoice — that framing is part of what makes it defensible. If you want the interactive version first, the calculator on the TrimCI landing page implements the same logic with your own numbers.

Why a model

Budget conversations run on numbers. "CI keeps failing and it's killing us" is true in most engineering organizations and moves no budget at all, because it competes against feature requests that arrive with revenue projections attached. To argue for time spent on pipeline health — fixing flaky suites, caching dependencies, splitting slow jobs — you need a dollar figure for the status quo.

There are two ways to get that figure wrong. The first is not having one, in which case CI hygiene loses every prioritization meeting by default. The second is presenting a suspiciously precise one — "failed builds cost us $83,412 per year" — that collapses the first time someone challenges an assumption you cannot name. A model beats both: it states its inputs, shows its arithmetic, and turns disagreement into a productive argument about input values instead of a credibility fight about the method.

A model also corrects a systematic bias. CI cost has a visible line item — the compute bill — and an invisible one: engineer attention. Because only the first shows up in an invoice, teams routinely optimize the small term. The model below makes the invisible term explicit, and in every realistic configuration it is the larger one.

The formula

The monthly cost of failed builds, in a form you can put in a spreadsheet:

monthly cost ≈ F × [ (D + S) × R × (1 + q) + M × c ]

Each term earns its place. Here is what it represents and how to defend it.

Engineer minutes (D)

When a build fails, someone opens the log, reads the traceback, decides whether the failure is real or noise, and either fixes the code, fixes the pipeline, or re-runs and watches. Even the fastest path — recognize a known flaky job, click re-run, glance back later — consumes minutes. The slow path, where the failure is unfamiliar and the log is 8,000 lines of stack trace, consumes an afternoon. A default of 10–15 minutes per investigated failure averages the quick dismissals against the occasional deep dig, and you can replace it with your own number by timing the next ten failures your team handles.

Context-switch tax (S)

The diagnosis minutes are not the whole human cost, because the engineer was doing something else when the red X arrived. An analysis of 10,000 recorded programming sessions from 86 developers found that a programmer takes 10–15 minutes to start editing code again after resuming from an interruption, and, when interrupted mid-edit, resumes within one minute only about 10% of the time (Parnin, "Programmer Interrupted"). A controlled study of interrupted office work found that people do complete interrupted tasks — but compensate by working faster, at the price of significantly more stress, frustration, time pressure, and effort (Mark, Gudith, and Klocke, CHI 2008).

A note on a number you may have seen: the widely quoted "23 minutes to refocus" figure does not appear in that CHI paper — it comes from the same researcher's interview remarks. The model here uses the directly published, more conservative programmer-specific figure: 10 minutes of resumption tax per investigated failure. If your team disputes it, halve it; the conclusion below survives.

Wasted compute (M × c)

The failed attempt burned real runner minutes across all its parallel jobs, and the retry burns them again — that second attempt is pure retry tax, compute that buys no new information about the code. Sum the job-minutes of the failed attempt, double it for the retry, and multiply by your per-minute rate.

As of 2026-07-28, GitHub lists standard 2-core Linux hosted runners at $0.006 per minute, Windows at $0.010, and macOS 3-core/4-core at $0.062 (larger macOS sizes run to $0.102) (GitHub Actions runner pricing) — how those minutes are metered is its own subject, covered in GitHub Actions billing, explained. On GitLab the unit is the compute minute, with its own multipliers. For self-hosted runners, use your amortized infrastructure cost per minute.

Notice the shape of this term: a failed pipeline that burns 60 job-minutes including its retry costs about $0.36 on standard Linux runners. That is the punchline of the whole model — the term everyone can see on an invoice is usually cents. It stops being cents on a macOS fleet, on large runners, or at the scale where CI compute is a five-figure monthly line — but for most teams, the humans dominate.

Queue-wait multiplier (q)

A failure delivers its verdict twice: once when the run fails, and again when the retry or the fix confirms green. Both passes wait in the same runner queue as everything else, and failures cluster exactly when queues are worst — busy afternoons, release days, the hour before a deadline. During congestion, a fix-verification run can spend as long queued as running, which stretches the engineer's attention window: more checking back, more partial context switches, a later merge. (If your queues are chronically long, that is a separate problem with its own causes — see why is my CI pipeline slow.)

This is the fuzziest term in the model, so treat it accordingly: apply it only to the human terms, default it to 10–30% based on how congested your runners are at peak, and set it to zero in your conservative scenario so nobody can accuse the model of padding.

Honest inputs

The formula is only as defensible as its inputs. Four of them deserve care.

Count investigated failures, not raw failures. Not every red run costs human attention. When the main branch breaks, twenty downstream runs may fail from one root cause that gets investigated once. Known flaky jobs get re-run without diagnosis — they skip D but still pay the retry tax in compute. A defensible default is that 50–70% of failures get real attention. Use decisive runs — failures plus successes — as the denominator for your failure rate, and fix one treatment for cancelled runs (TrimCI counts them on the failure side; dropping them entirely is the other defensible choice), or the rate will drift with unrelated noise.

Use a fully loaded rate, and say so. An engineer's cost to the company is salary plus benefits, employer taxes, equipment, and overhead. A common convention is salary times 1.25–1.4; pick a multiplier, state it, and divide the result by 124,800 (2,080 working hours × 60) to get a per-minute rate. Using a blended team rate rather than individual salaries keeps the model both simpler and less awkward to present.

Measure your failure rate if you can. A planning range of 5–15% of decisive runs is a reasonable starting bracket, but it is an assumption, not a benchmark — your dashboard knows your number. If you must assume, assume 10% and label it loudly as the input most worth replacing with data.

Sample your own diagnosis time. The next ten failures your team handles, note two timestamps: when someone opened the failure and when they returned to their previous task. The average is your D + S, measured instead of modeled — the strongest possible answer to "where does 22 minutes come from?"

Worked examples

The following three teams share one set of assumptions, all replaceable: 5 decisive runs per engineer per workday, 21 workdays per month, a 10% failure rate on decisive runs, 60% of failures investigated, D = 12 minutes, S = 10 minutes, q = 0.2, a fully loaded rate of $100/hour ($1.67/minute), and 60 wasted compute minutes per failure (failed attempt plus retry) on Linux runners at $0.006/minute.

Per investigated failure, the human cost is (12 + 10) × 1.2 = 26.4 minutes, about $44. The compute cost is about $0.36 — under 1% of the total. Then it is just multiplication:

At 80 engineers, failed builds cost roughly one senior engineer's fully loaded compensation per year — a comparison management understands immediately.

Point estimates invite false confidence, so present a range. Here is the 25-engineer team under three input sets:

A spread of nearly 6× between conservative and aggressive is not a weakness of the model — it is the honest answer, and presenting it as a range is precisely what makes the central estimate credible. Even the conservative case funds meaningful pipeline work. The landing-page calculator runs this same arithmetic on your team size and failure rate if you want a starting point in under a minute.

What it leaves out

A defensible model is explicit about its blind spots. This one has four.

These are model estimates, not payroll. Cutting failed-build waste in half does not free $3,500/month in cash for a 25-engineer team. Engineers do not stop being paid during CI triage, and recovered time returns as engineering capacity and faster feedback, not as a budget line you can reallocate. Present the number as the value of attention currently spent on failure handling — never as recoverable spend. Overselling this is the fastest way to lose the room.

Some failures are the system working. A real failure that catches a bug before merge is CI doing its job; the model prices the cost of handling it, not the (much larger) value of catching it. The waste concentrates in the other kind — flaky tests, infrastructure hiccups, broken runners — where the same handling cost buys nothing. Separating the two is analysis work the model cannot do, which is why measurement matters more than modeling in the long run.

Double counting is easy. If you price retries inside M, do not also count each retry as a separately investigated failure. If your team's diagnosis time already includes waiting for the verification run, drop q. One cost, one term.

The second-order costs are real but unpriced. Slow, unreliable CI changes behavior: engineers batch changes to avoid the pipeline, reviews stall waiting for green, deploys get postponed, and the habit of clicking re-run becomes culture. None of that fits in the formula, which means the model systematically undercounts. Say so — it is the rare caveat that strengthens your case.

Presenting to management

The model earns its keep in a prioritization conversation. Five practices make it land.

Lead with the range, not the point. "Failed builds cost us roughly $2,500 to $14,000 a month; our central estimate is $7,000" is a stronger opening than any single number, because it demonstrates you have already stress-tested your own claim.

Name every assumption and invite replacement. Bring the spreadsheet. The fastest way to get a skeptical director on side is to let them change the fully loaded rate to their own number and watch the conclusion survive.

Translate dollars into capacity. The 25-engineer central case spends about 4,200 engineer-minutes a month on failure handling — roughly nine engineer-days. "We spend nearly two working weeks a month reacting to red builds" often moves a room that a dollar figure does not. Similarly, CI cost per contributor turns any tooling spend into a per-head ratio that is easy to weigh against the waste.

Anchor the number to specific fixes. A cost estimate alone invites sympathy; a cost estimate next to "three pipelines produce 61% of our failures, and two of them fail the same way" invites a decision. Pair the model with your actual top offenders — this is exactly what CI pipeline failure analysis is for.

Promise outcomes, not refunds. The deliverable of pipeline work is faster feedback, fewer interruptions, and reclaimed capacity — not a smaller payroll. Teams that frame it honestly get to come back next quarter with a before/after chart. For worked narratives of how different teams frame this case, see the scenarios page.

From model to measurement

A model with assumed inputs gets you budget attention. Measured inputs get you action, because they tell you which failures to fix first: the real failure rate on decisive runs, the actual duration of failed pipelines, how often runs need a second attempt, and how long verdicts sit in queue. Every assumption in the tables above is a placeholder for a number your own pipeline history already contains.

TrimCI computes the measured half of this model from pipeline metadata alone — runs, jobs, timing, and logs, with no access to source code. Synced run history becomes failure rates over a decisive denominator (failures plus successes, with cancellations counted on the failure side and skipped and neutral runs kept out), a GitHub-only re-run tax section — what share of runs needed a second attempt and the approximate minutes those discarded attempts burned (GitLab exposes retried jobs only inside the same pipeline and gives no run-level attempt counter, so the re-run tax section is GitHub Actions-only) — queue-time breakdowns, and an estimated loss for the window you are looking at, computed the same rate-times-minutes way as this article: a blended engineer hourly rate and developer count you set per organization, against a fixed per-failure minute assumption. Set an optional per-minute compute rate and PDF reports add a compute-spend section beside it. The granularity is the run and job level — TrimCI does not do per-test flaky detection — and history windows run from 7 to 60 days depending on plan, so check that yours covers the trailing period this model needs. The calculator is the two-minute version of the business case; a dashboard over your own runs is the defensible one.