A Worksheet for Sizing Your CI Pipeline's Real Cost
Engineering teams tend to know their cloud hosting bill down to the dollar and have almost no idea what their CI pipeline actually costs, both in compute spend and in the engineering hours spent waiting on it. That second number is usually bigger than people expect, and it's the one you can build a worksheet around instead of just guessing.
Here's a walkthrough you can fill in with your own numbers this week.
Column one: compute minutes per week
Pull your CI provider's usage report and total up compute minutes across all pipelines for a representative week, not a slow week and not a deploy-heavy week. Break it down by pipeline: unit tests, integration tests, security scans, build and packaging, deployment. This is the number most teams already half-know, since it usually maps to a line item on an invoice.
Column two: wall-clock wait time per engineer
This is the number almost nobody tracks. If a pipeline takes fifteen minutes end to end and an engineer pushes five times a day waiting on green before moving to the next task, that's over an hour of wait time per engineer per day, even if they're nominally doing something else while it runs. Multiply that by your engineering headcount and a typical work week, and you get a rough weekly hours figure that's often larger than the compute bill in dollar terms, once you convert it using loaded engineering cost.
Say your pipeline averages twelve minutes and you have fifteen engineers pushing an average of four times a day: that's roughly twelve hours of aggregate wait time across the team, every single day. Even if engineers are context-switching to other work during part of that wait, a meaningful share of it is pure friction, the moment where someone was about to move to the next task but held off to see if the build passed first.
Column three: where the time actually goes
Break the fifteen minutes (or whatever your number is) down stage by stage: how much is dependency installation, how much is the test suite itself, how much is security scanning, how much is packaging and upload. This is usually where teams find the biggest, cheapest win: a dependency cache that isn't actually being hit, a test suite running serially when it could shard across parallel runners, or a security scan duplicated in two stages that could run once.
Column four: the fix, prioritized by minutes saved times pipeline runs
Once you know where time goes, prioritize fixes by minutes saved multiplied by how often that stage runs, not by which fix looks most interesting to build. A five-minute fix to a stage that runs two hundred times a week beats a twenty-minute fix to a stage that runs five times a week, even though the second one sounds more dramatic in a planning meeting.
- List each pipeline stage with its average duration and weekly run count
- Multiply duration by run count to get weekly minutes consumed per stage
- Sort by that total, not by raw duration, to find your real priority order
- Re-measure after each fix; caching and parallelization sometimes interact in ways that aren't obvious upfront
What this worksheet tends to reveal
Most teams that fill this out for the first time find one or two stages responsible for the majority of total pipeline time, a dependency install that isn't cached properly, or a full end-to-end test suite running on every commit instead of just on a merge to the main branch. Fixing those one or two stages typically recovers more wait time than a broad, unfocused optimization pass across the whole pipeline, and it gives you a concrete number to report back on when someone asks whether the effort was worth it.
It also tends to surface a second, quieter finding: a pipeline stage that used to matter and no longer does, a legacy integration test suite for a service that was decommissioned months ago, still running on every single commit because nobody remembered to remove it. Deleting dead stages is often the single fastest win on the whole worksheet, since it costs nothing to remove and the minutes saved apply to every future run indefinitely.
What Good Looks Like
The pipeline's compute cost and aggregate engineering wait time are both known numbers, tracked stage by stage, with fixes prioritized by minutes saved times run frequency rather than by instinct.
Building The Capability (5-Stage Skill Ladder)
How to Get Started
Frequently Asked Questions
How do we convert wait time into a dollar figure leadership will care about?
Multiply your weekly aggregate wait-time hours by a loaded engineering cost per hour, which most finance teams can provide. Presenting it as a dollar figure alongside the compute bill usually reframes the conversation from a technical nice-to-have into a straightforward cost-reduction case.
Is parallelizing tests always the right fix for a slow pipeline?
Not always. Parallelization helps when the suite itself is the bottleneck, but if dependency installation or a security scan is the real culprit, adding more parallel test runners won't touch the actual slow stage. Measure first, then pick the fix that matches what you actually found.
How often should we redo this worksheet?
Whenever the pipeline noticeably changes, a new security gate gets added, the test suite roughly doubles, or a new service joins the monorepo, and as a baseline check at least twice a year even without an obvious trigger.
About the numbers
This guide doesn't quote a sourced benchmark. Figures in it are estimates or general guidance, so check them against your own numbers.
Related Guides
Building a CI/CD Pipeline That Actually Catches Bugs
How to build a pipeline that blocks real regressions instead of just style errors, from test selection to what actually belongs as a merge gate.
Building a CI/CD Pipeline That Doesn't Slow You Down
How to build a CI/CD pipeline engineers actually trust: what belongs in it, why speed matters more than coverage, and how deploy frequency really changes.
What Your CI/CD Pipeline Actually Costs You
A way to think about CI/CD pipeline cost beyond the compute bill, including engineer waiting time, flaky test triage, and what to fix first.
Catching a Breaking API Change Before Your Customer Does
How automated contract testing catches breaking changes between services before they reach production, and where teams usually skip it.
CI/CD Stages That Actually Catch RAG Pipeline Regressions
A standard test suite misses RAG failure modes. Here are the CI/CD stages worth adding: retrieval gates, model version checks, and a real test index.
Where to Put Security Gates in Your CI/CD Pipeline
A decision guide for placing SAST, dependency, and secrets scanning in your CI/CD pipeline so gates catch real problems without slowing every deploy.