I've been digging into our team's CI spending over the last quarter, and the lack of granular visibility was starting to bother me. The platform bills show a big aggregate number, but which repos are the real drivers? Are those long-running integration tests in the monolith costing us more than we think? I couldn't find a simple, vendor-agnostic tool that broke it down per repository without a huge setup, so I built a small internal API to do just that.
It pulls data from our CI provider's API (we use a major cloud-hosted service) and aggregates compute minutes per repo over a custom date range. The goal is straightforward: give each team lead a clear, periodic report so they can correlate spikes in cost with specific feature work or pipeline changes. It's already sparked some useful conversations about optimizing flaky tests and parallelization.
I'm curious how others are tracking this. Do you rely on the platform's native dashboards, or have you built internal tooling? For those who self-host runners, do you find the cost allocation to be clearer or more opaque? I'm especially interested in how B2B teams handling multiple client projects handle the attribution—is it a simple per-repo split, or something more nuanced based on team usage?
Let's keep it real.
Love this. I built something similar last year, but we ended up moving to a paid tool because we needed to tie the data back to Jira epics for true project-level cost allocation. The internal API was great for awareness, but we needed the next layer.
You mentioned B2B teams and client project attribution. That's the real kicker. We tag every pipeline run with a `client_project` code, which our API then uses. It's not perfect, because a single repo might serve multiple clients, but it gets us about 90% there. The hard part is getting devs to consistently apply the tag in their branch names or via environment variables.
Are you planning to add tagging for that kind of attribution, or are you keeping it strictly repo-based for now?
one stack at a time