Just built a simple API to track CI minutes per repo

cost.analyst.liam · 2026-09-25T14:26:57Z

After implementing a simple internal API to instrument our CI pipeline and track minute consumption per repository, I have arrived at a conclusion that many teams likely overlook: the aggregate cost of CI/CD is rarely a simple function of total compute minutes. The true cost is a multi-variable equation heavily dependent on the underlying resource profile, concurrency, and the often opaque pricing tiers of your provider. Our initial motivation was straightforward: we needed to charge back costs accurately to product teams and identify optimization opportunities. The API taps into our CI controller's event stream, tagging each job execution with repository, runner type (instance family), duration, and the resultant cost based on our provider's per-minute rate for that specific runner. The data revealed several critical patterns: * **The concurrency multiplier:** Our monthly invoice is not just `(sum of job minutes) * (blended rate)`. It is `(peak concurrent jobs) * (instance hour cost)`. A high degree of parallelism, while speeding up builds, forces provisioning of multiple runners, leading to significant idle time costs if those runners are not efficiently shared or scaled down. We observed our peak concurrency drove a 40% higher baseline cost than a simple minute-aggregation would suggest. * **The hidden cost of "free" minutes:** Many managed CI services offer a base tier of free minutes, but these are typically attached to their lowest-performance machines. Using higher-performance machines for faster builds consumes these minutes at a 2x-4x multiplier. Our data showed Team A, using `medium` runners, burned through their monthly free allowance in the first week, while Team B, using `large` runners for heavy workloads, exhausted theirs in two days, making their effective cost per minute substantially higher. * **Storage and egress leakage:** The CI/CD cost model extends beyond compute. Each job generates artifacts, logs, and cache data. We found that 15% of our associated cloud bill was from object storage requests and inter-region data transfer fees from caching layers and artifact storage, costs not attributed to any single repository by the provider's native billing. The next phase of analysis will involve comparing this self-hosted runner model—with its visible but controllable infrastructure costs—against a fully managed CI service. The key variables I am modeling include: * The administrative overhead of runner maintenance and security patching, quantified as an engineering time cost. * The differential in compute minute pricing between a self-hosted EC2/GCE instance and a managed CI's per-minute rate, factoring in reserved instance discounts for the former. * Whether our observed usage patterns (many short jobs vs. few long jobs, spiky vs. consistent demand) align better with a per-minute or infrastructure-commitment model. Preliminary spreadsheet modeling suggests a crossover point where managed services become prohibitively expensive, but that point is highly sensitive to the chosen machine types and the team's ability to right-size and schedule their self-hosted infrastructure. I am interested in hearing from others who have undertaken similar instrumentation. Specifically, what cost allocation metrics did you find most actionable for engineering teams, and how did you model the total cost of ownership when evaluating managed versus self-hosted solutions?

Page 4 / 4 Prev

CI/CD Cost & Pricing Analysis

Last Post by darrenk 3 days ago

46 Posts

44 Users

0 Reactions

9 Views

RSS

darrenk

(@darrenk)

Honorable Member

Joined: 3 months ago

Posts: 392

27/09/2026 5:08 am

The concurrency multiplier is the killer, yeah. Our team hit that exact wall last quarter. We were optimizing individual job times but the bill didn't move - we were still hitting the same peak runner count for a short window each day. It's frustrating when the metric you're watching (total minutes) isn't the one you're actually paying for.

ReplyQuote

Page 4 / 4 Prev

Forum Icons: Forum contains no unread posts Forum contains unread posts

Topic Icons: Not Replied Replied Active Hot Sticky Unapproved Solved Private Closed