Everyone's talking about scaling their CI/CD pipelines, but I haven't seen many people talk about the actual bill. They just nod along when their favorite SaaS platform shows a pretty chart of "build minutes" and says it's all going swimmingly. I got tired of the mystery, so I wired up a Grafana dashboard that pulls data directly from our internal accounting and Git systems. The goal was simple: correlate every single commit, merge request, and deployment with its actual cost in compute resources, both on our self-hosted runners and the unavoidable managed ones.
The initial setup wasn't trivial. You have to pull data from your cloud provider's billing API (or your own on-prem metering), tag every runner instance with a project and team identifier, and then join that with your Git provider's webhook data. It's a data plumbing nightmare, but once it's flowing, the picture it paints is brutally clear. You start seeing things like a single, poorly optimized integration test suite for a minor library burning through more monthly compute than the entire staging environment for your flagship product. Or you see the true cost of that "free" tier of the managed service, which of course isn't free—it's just bundled into a bloated seat license for another product.
What's fascinating, and frankly a bit depressing, is the comparison it allows. We can now see the exact cost per pipeline minute for our self-hosted infrastructure on a per-project basis, including all the depreciation, power, and admin overhead we've allocated. Stack that right next to the per-minute rate from the managed CI vendor. The vendor's rate looks low on the surface, until you realize their "performance boost" agents are the only ones that meet our SLA, and those carry a 400% premium. The dashboard also highlights the lock-in tax: the projects using vendor-specific features have a 70% higher migration cost estimate attached to them, which we calculate based on engineer-hours to rewrite pipelines.
This isn't about being cheap. It's about understanding the financial sinkholes. I've watched teams spin up a dozen parallel jobs because "the concurrency is free," not realizing they've just moved from a resource-constrained queue to a pay-per-use meter that has no ceiling. The dashboard now flags projects with runaway concurrency or average job durations that spike week-over-week. The next step is to bake this cost data right into the merge request view, so engineers see the approximate infra cost of their change alongside the linting results. Because if you aren't measuring it, you're just writing a blank check and calling it "velocity."
Just my two cents
Skeptic by default
Oh man, the moment you get that data flowing is equal parts terrifying and enlightening. It's like turning on the lights in a teenage boy's bedroom. You were vaguely aware of the mess, but seeing the specific, moldy pizza boxes of wasteful pipeline configs is something else entirely.
My "favorite" discovery was a team that had a "deploy to staging" job that was, I kid you not, pulling the entire multi-gigabyte base image on every single pipeline run because they'd never set up a proper layer cache. The cost was buried in the overall infra bill, but the dashboard showed it was their little service chewing through more storage egress than our data warehouse.
The real fun starts when you show these dashboards to the engineering leads. That's when you find out who's actually cost-aware and who's been playing with the company credit card in the cloud sandbox. 😅
it worked on my machine