Your CI Bill Is Payroll, and Nobody Has Priced It

TL;DR: You know your CI compute bill to the cent. The bigger CI bill - engineers waiting on a 40-minute gate, several runs per PR - has no invoice, so nobody has ever priced it. Three numbers from your CI logs (duration, runs per merged PR, share of runs that block a human) turn it into engineer-hours per week; a disclosed loaded rate turns the hours into money a CFO accepts. Then fix flaky tests and the longest job first, and claim savings only when the measured rate falls.

You negotiated the CI vendor contract yourself. You know the compute spend per month, per runner, per minute: it's a line item, so it gets scrutiny.

Now stand behind an engineer at 15:40 on a Thursday. They push a one-line fix. The gate takes 40 minutes. A flaky test fails it. Rerun: green, 40 more minutes, and the afternoon is gone - for a diff you could review in a coffee break. Multiply by every PR, every engineer, every day.

That's also the CI bill. It's paid out of payroll, your most expensive line item, and because no invoice ever arrives, nobody has priced it. A 40-minute pipeline is a purchasing decision no one signed.

Why the payroll side dwarfs the compute side

The pipeline sits inside every iteration of every change, so its cost scales with your whole delivery flow rather than your runner count. LinearB's benchmarks across 8M+ PRs put elite cycle time (first commit to production) under 25 hours at p75. A PR that needs three gate runs at 40 minutes each has spent two of those hours inside the pipeline alone, before a human has reviewed a line. Slow CI quietly pushes teams toward the same failure modes as slow review: bigger batches ("I'm not paying that gate twice for two small PRs"), stale branches, and merge trains that turn Friday into a lottery.

And the waiting isn't free just because engineers alt-tab. Parnin & Rugaber's interruption research across 10,000+ programming sessions found only about 10% of interrupted sessions resumed real editing within a minute, and roughly 30% took over half an hour to get back to it. A 40-minute gate costs a context switch out and a context switch back, per run. In a 41-hour average workweek already heavy with maintenance, the switches compound into exactly the kind of process leak that never appears in any budget review.

Price it honestly: the arithmetic and the rules

The dishonest version bills every CI minute as an engineer-minute. Don't. Anyone financially literate will shred it, and they should. Three rules keep the number defensible:

• Count only human-blocking runs. A PR gate someone is waiting on, a red main branch freezing merges, a failed deploy being retried. Nightly builds and async suites cost compute while nobody waits.
• Hours first, money second. "Blocking pipeline waits cost us roughly N engineer-hours a week" survives any meeting on its own.
• Disclose the rate. Convert with a fully-loaded rate and print the assumption next to the result. The MIT rule of thumb is 1.25-1.4 times base salary, and BLS puts benefits at 29.7% of employer cost.

A deliberately hypothetical shape, to show the arithmetic (plug in your own logs): a team merging 40 PRs a week, with a 35-minute gate and 2.5 runs per merged PR, has about 58 hours of elapsed gate time weekly. If a third of those runs genuinely block someone (your logs will tell you; don't guess generously), that's roughly 19 engineer-hours a week. Call it a two-and-a-half-day-per-week invoice at your loaded rate, whatever your currency. These aren't a real team's numbers. The point is that yours are three queries away.

Do this first - free, this month

1. Pull the three numbers: p50 and p90 pipeline duration, runs per merged PR, and the share of runs that block a human. Every CI system's API has this.
2. Count the red loop. Failures that get rerun without a code change and pass are flaky-test tax: each one bought a full gate of wait plus two context switches for nothing. Quarantine the worst offenders this week.
3. Split the gate from the suite. The merge-blocking path should carry only what protects the merge; move the slow, broad suite async. This is often a config change with a flow-efficiency payoff far beyond CI.
4. Cache or parallelize the single longest job. One job usually dominates the duration; fixing the p90 also un-punishes small PRs, which slow gates silently tax the most.
5. Re-measure monthly against your baseline. Duration down, runs-per-PR down, blocking share down. That measured delta is your savings claim. A projection is not a saving; a fallen rate is.

How you'd actually see it in Busfactor

Busfactor treats CI as what it is: a payroll line. The quality view tracks CI duration and prices the burn in your configured currency from your own cost model, next to the hotspot and test-presence signals that usually explain why the pipeline got slow. On the Money view, it lands as one decomposed drain line among the others - your run counts, your durations, your rate - each fix carrying a payback estimate at disclosed, editable assumptions, so "speed up the gate" can be ranked against every other fix competing for the same sprint.

The honest limits: rates are labeled as estimates until you set real compensation data, and we don't see your CI vendor's invoice, so this covers the payroll side only. No line ever claims hours "back" either. A saving shows up only when your measured rates actually fall.

That's a smaller promise than some dashboards make. It's also one that survives a CFO.

The door

This is one of the cheapest fixes in engineering economics: no reorg, no headcount request - three queries, a flaky-test quarantine, one cached job. Price the gate this week, in hours first. Either the number is small and you've bought peace of mind, or it's large and you've found budget sitting in a progress bar. The next time someone asks what engineering costs, one more line of the answer is itemized instead of vibes.