I've been conducting a longitudinal analysis of CI/CD pricing models across the major cloud-native providers (GitHub Actions, GitLab SaaS, CircleCI, etc.) and a growing trend has emerged that, in my professional opinion, warrants significant scrutiny: the shift towards "pay per concurrent job" as the primary pricing dimension.
Historically, many platforms used a simpler model: you paid for a certain number of compute minutes per month. While this had its own opacity issues (e.g., varying minute costs for different OSes and hardware specs), it was at least directly tied to your actual compute consumption. The new paradigm abstracts this further. You now purchase a "concurrency slot"—the right to run a single job at a time—and are then billed separately, often per-minute, for the compute that runs *within* that slot. This creates a multi-variable cost equation that is notoriously difficult to model and predict.
Consider a simplified benchmark scenario:
* **Provider A:** $50 per concurrent job (slot) per month, plus $0.03 per compute-minute (Linux).
* **Provider B:** $0.04 per compute-minute, with a managed queue and no slot limitation.
For a team with highly variable build patterns—bursts of 10 parallel jobs for 30 minutes twice a day, but otherwise 1-2 jobs running—the cost divergence is staggering. With Provider A, you must provision 10 slots to handle your peak, paying for those 10 slots for the *entire month*, even though they sit idle 95% of the time. Your cost becomes dominated by the slot reservation, not the actual compute consumed.
My primary objections are as follows:
* **Inefficient Resource Allocation:** It incentivizes under-provisioning to save money, directly increasing developer wait times during peak periods. This is a direct tax on productivity.
* **Obfuscated Total Cost:** The separation of "slot" and "compute" costs makes true cost-per-build calculations needlessly complex. It becomes a multi-linear optimization problem most engineering teams are not equipped to solve.
* **Predatory Lock-in for Growth:** As your team and commit frequency grow, your need for parallel jobs grows linearly or exponentially. The cost scales with your *peak parallel need*, not your *total compute usage*. A 2x increase in developers might necessitate a 4x increase in concurrency slots, leading to super-linear cost inflation.
I've modeled this against self-hosted runners on a reserved cloud instance, and the break-even point is often at a surprisingly low number of concurrent jobs. The managed service's premium for orchestration and ease-of-use is justifiable, but the concurrency tax appears to be a pure margin play on a psychological aversion to queueing.
Has anyone else performed a rigorous, reproducible cost analysis on this? I am particularly interested in datasets showing monthly invoice breakdowns from these platforms, correlating commit/branch frequency with required concurrency, and any benchmarks comparing total cost of ownership against a bare-metal or cloud-instance runner fleet. The industry seems to be accepting this model without sufficient critical analysis of its long-term economic impact on engineering budgets.
numbers don't lie
numbers don't lie
It's not predatory. It's just a way to charge you for capacity you're probably already paying for elsewhere (idle VMs, underutilized licenses). The real gotcha is when they tie *compute cost per minute* to the slot tier. Buy a cheap slot? Your per-minute rate is often higher. So your "savings" on the slot fee evaporate if you actually run jobs.
You compared a flat per-minute rate to a slot+rate model. But what about the contract lock-in? Provider B's simple per-minute rate usually comes with a hefty annual commitment. Provider A's slot model is often monthly. That's the tradeoff they don't put on the pricing page.
always ask for a multi-year discount
I see what you're saying about the contract lock-in angle, that's a good point. But the way they tie the per-minute rate to the slot tier still feels like a pricing maze. It reminds me of old CRM license models where a "basic" user seat was cheap, but then you'd get hammered on API call overages or storage fees.
So you're basically forced to model two variables (slot count and runtime) instead of one, and guess wrong on either side. That's not transparency, it's just complexity you pay for.
That CRM comparison is spot on. We built a ton of Salesforce integrations, and the "cheap seat, expensive everything else" model is exactly the same playbook. It forces you into an optimization game you can't really win.
What's sneaky here is it turns engineering decisions into a direct financial lever. If your team writes a slower job that holds a slot for 20 minutes instead of 10, the cost impact is doubled. So you're not just buying compute, you're buying the *right to optimize*.
I've had to build dashboards just to track slot utilization vs. runtime cost, which feels like an internal tax. Anyone else doing that?