For a system under external maintenance, a cost revision request arrives from your contractor. A line item labeled "cost increases in CI/CD execution environments" shows a substantial sum. Asking the contractor yields discussions about build counts and durations. You understand the words, but cannot judge whether the dollar amount is reasonable.
Consultations about this issue are increasing. In most cases, the contractor is not overcharging; actual expenses have indeed risen. However, half the reason for the surge lies in how the mechanism works, and the other half stems from no one monitoring it.
Costs grow because nobody stops them
Continuous integration (CI) automatically runs builds and automated tests whenever code changes. It is essential for preserving quality and is now routinely included in maintenance contracts.
The problem lies in how it is billed: a usage-based model where you pay for what you run, with executions triggered by regular developer actions. Every time a single line of code is edited and saved, processes run for several to tens of minutes. Because the unit cost per run is tiny, no one pays attention.
Furthermore, no one in this workflow is incentivized to stop it.
- Developers consider automated tests a virtue and have no incentive to cut back
- Contractor managers do not monitor the running total until the invoice arrives
- Clients are unaware such usage-based expenses are being incurred in the first place
Consequently, builds on obsolete, unused branches run daily, and single pushes trigger duplicate test suites across three parallel pipelines, persisting unaddressed for years. In reality, costs did not suddenly jump—there was simply never an opportunity to realize how much they had grown.
What changed in 2026
GitHub Actions pricing revisions brought this dynamic into the open. Announced in December 2025, they were phased in across 2026 (About GitHub Actions price revisions — GitHub Blog).
The revisions moved in two distinct directions:
GitHub-hosted runners saw price reductions. Taking effect January 1, 2026, standard configurations saw price drops of around 25%. Looking only at this, costs should have fallen.
Meanwhile, the handling of self-hosted runners changed. Initially, a connection fee of $0.002 per minute was announced, but community pushback led to that specific charge being paused and re-evaluated (GitHub announces pricing model changes for Actions — gihyo.jp). However, starting March 1, 2026, self-hosted runner execution now consumes free included usage quotas.
In essence, the assumption that 'running on private infrastructure makes CI free' collapsed. Costs previously absorbed by contractors as internal server overhead became visible, metered consumption.
The concentration of cost review requests this year is largely driven by this newfound visibility.
Four things clients should verify
There is no need to dig into technical minutiae. Asking the following four questions provides the data needed to evaluate reasonableness:
| What to verify | Healthy state | State requiring review |
|---|---|---|
| Monthly execution count and total run time | Can provide exact numbers immediately | Stalls with "we will check" |
| What triggers execution | Limited strictly to changes affecting production | Runs on every branch and every save |
| Duration per execution | A few minutes to around fifteen minutes | Consistently takes 30 minutes or longer |
| Reviewed within the past year | Audited and pruned periodically | Untouched since initial setup |
The first row is the most telling. Inability to produce figures means nobody was monitoring usage. In that state, a proposed fee increase is likely just a direct pass-through of the invoice rather than a reasoned calculation. It reflects a lack of governance rather than bad faith.
The fourth row carries similar weight. A CI pipeline left untouched for years has accumulated all tests and scripts added over time. Without anyone assigned to prune it, resource consumption can only trend upward.
Three avenues for cost reduction, and the order to tackle them
Approaches to trimming costs fall into three broad categories:
Reduce execution frequency. Stop running full pipelines on every intermediate commit, reserving heavy suites for merges bound for production. This delivers high savings with minimal risk to quality. Often, simply terminating recurring schedules on abandoned branches yields immediate reductions.
Shorten execution duration. Introduce caching to reuse intermediate results, parallelize test jobs, and remove legacy dependencies. This involves engineering effort that incurs billable contractor hours, so weigh engineering costs against anticipated savings.
Switch execution environments. Switch providers or migrate workloads to private infrastructure. While cost profiles change, migration overhead and operational maintenance responsibilities shift as well. Migrating without deciding who troubleshoots broken CI pipelines will cost more later.
The sequence of implementation should strictly follow this order. If a contractor proposes switching environments first, verify whether the top two steps were attempted. Changing environments without curbing run volume simply continues wasteful execution on cheaper infrastructure.
Recent default settings delaying dependency update pull requests by three days reflect this same trend against unconstrained automation (Dependabot defaults to a 3-day delay). Metered pricing for AI development assistants shares the exact same dynamic, as discussed in Visualizing token consumption.
Request cost visibility rather than flatly rejecting increases
Practically speaking, avoid deciding on the price increase immediately. Negotiating without underlying metrics only leads to mutual frustration.
Instead, request a month-by-month breakdown of execution counts, total run times, and costs for the last three months. A contractor should be able to produce this data; inability to do so confirms the absence of tracking. Either outcome clarifies what needs to be determined next.
Next, examine the distribution of executions. In most environments, a handful of top workflows account for the vast majority of runs. Whether optimization requires adjusting just those few jobs or overhauling the entire system determines the scope of work. With these facts in hand, you can objectively compare accepting the revised fee against commissioning an optimization project first.
The overall discussion of how to read maintenance cost breakdowns is summarized in Maintenance Costs for Business Systems, and how to lock down cost structures during the ordering stage is covered in Client Guide to Successful System Development Outsourcing.
Whether you want an objective third-party review of a maintenance cost breakdown presented by a vendor or want to organize your operational costs including CI/CD, GleamHub is here to assist through our development, AI, and automation consultations. Because optimal configurations vary based on requirements, we provide customized estimates. Please contact us via Inquiries.
Sources
- GitHub Actions Price Changes — GitHub Blog (December 18, 2025)
- GitHub Announces Changes to Actions Pricing Structure: Reconsidering Self-Hosted Runner Charges Following Feedback — gihyo.jp
- GitHub Actions Revises Pricing: Price Cuts for GitHub-Hosted Jobs, Self-Hosted Jobs Billed at $0.002 per Minute — Publickey
- About Billing for GitHub Actions — GitHub Docs
