FinOps for Delivery Pipelines

There are two cloud bills in most engineering organizations, and only one of them gets watched. The first is production — the servers, databases, and load balancers that serve customers, and the subject of general cloud FinOps. The second is the delivery pipeline itself — the fleet of CI runners that compiles, tests, scans, and packages every single commit before it ever reaches production. Nobody's a customer of that fleet; it doesn't show up on a product roadmap; and because CI/CD pipelines run constantly, in the background, on every push, its bill quietly compounds while everyone's attention stays on the servers customers actually touch. This page is scoped narrowly and deliberately: not cloud cost management in general, but the specific, recurring spend generated by the act of shipping code — runner minutes, redundant builds, and the shared infrastructure twenty teams push into at once.

Why the pipeline needs its own cost lens

☺ Like you're 10: The production servers aren't the only thing that costs money — the machine that builds and tests your code before it ever reaches them costs money too, and almost nobody's watching that meter.

General cloud FinOps — allocating a shared production bill down to the team and workload that caused it — is its own deep discipline, and this course doesn't repeat it here. What it usually leaves out entirely is the compute layer that runs before production: the CI runners that check out your repo, install dependencies, compile, run every test suite, build container images, and push artifacts, on every single push, every single day, whether or not that push ever ships. That work is real, metered compute — GitHub Actions and GitLab CI both bill it by the minute, self-hosted runners cost real EC2 or on-prem hardware whether they're busy or idle, and CircleCI bills it in credits — and at any organization running more than a handful of repos, it adds up to a line item finance eventually asks about, usually right after someone notices it grew 40% quarter over quarter with no corresponding growth in headcount.

This maps directly onto CALMS's Measurement pillar, the same way the DORA metrics do — you cannot optimize a cost you cannot see — and onto Lean, because small batch sizes were never free; they trade a large, infrequent cost for many small, frequent ones, and if nobody prices the frequent ones, "small batches" quietly becomes "more total spend" instead of the throughput win it's supposed to be. The rest of this page works through four concrete levers — right-sizing, caching, per-team visibility, and pipeline design — and then the one place they all collide: what happens to your CI bill when you chase deployment frequency without touching any of them.

Anatomy of a CI/CD bill

☺ Like you're 10: One push to your code can quietly turn into a dozen separate jobs running at once — and the bill is every one of those jobs' minutes added together, not just the one you were thinking about.

The formula behind every CI invoice is short: cost = rate per minute × minutes run × number of parallel jobs. All three levers matter, but the third is the one teams most often forget to look at, because a pipeline-as-code matrix build is designed to hide it. A workflow that tests against 3 operating systems and 4 language versions isn't one job — it's twelve, all triggered by the same single push, each billed independently. A 5-minute test suite that "feels like" 5 minutes of CI cost is actually 60 runner-minutes the moment a matrix multiplies it, and the person who wrote strategy: matrix for good reasons — real cross-platform coverage — rarely goes back to ask whether every cell in that matrix still earns its keep.

Hosted-runner rates are a real, published starting point, not a rumor: GitHub Actions bills Linux 2-core runners per minute, and applies roughly a 2× multiplier for Windows and a ~10× multiplier for macOS on the same job — a rate difference driven by Apple's hardware licensing, not by macOS jobs being ten times more expensive to run. GitLab CI/CD meters usage as a monthly "compute minutes" quota rather than a flat per-minute price, and CircleCI bills in credits that vary by executor class (Docker, machine, macOS, GPU). Treat every number above as illustrative — all three vendors revise pricing and free-tier allowances often enough that you should read them straight off the vendor's current pricing page before building a budget on them, the same hedge this course's own certification pages give exam costs and formats.

Right-sizing CI runners and build minutes

☺ Like you're 10: Handing every job the biggest, fastest machine wastes money per minute; handing every job the smallest, slowest one can waste just as much by making the job run long enough to cost more anyway.

Right-sizing a CI runner is the same idea as right-sizing a production VM, aimed at a different bill. A linter that finishes in 20 seconds gains nothing from an 8-core runner — it's paying a higher per-minute rate for cores it never touches. But the opposite mistake is just as real and less often caught: a CPU-bound compile or a large monorepo's full test run, forced onto an undersized runner, can take three or four times as long to finish — and because you're billed rate × minutes, a slow cheap runner sometimes costs more in total than a fast expensive one for the exact same job. There's a real optimum, and it's found by measuring, not guessing.

The most common waste source in the self-hosted row isn't a wrong instance type — it's a fleet sized for peak PR volume that then runs at that size around the clock. A pool of twenty self-hosted runners provisioned for a Tuesday-afternoon crunch is mostly idle capacity every night and every weekend, and idle self-hosted compute bills exactly the same as busy self-hosted compute. Tools like actions-runner-controller (ARC) for GitHub Actions on Kubernetes, or GitLab's autoscaling Docker Machine and Kubernetes executors, scale the runner pool toward zero when no jobs are queued and back up when they are — turning a fixed 24/7 cost into one that roughly tracks actual pipeline activity. This is the same reconciliation idea covered in infrastructure as code — declare the desired pool size as a function of queue depth, and let a controller keep it converged — just pointed at build capacity instead of application capacity.

Caching: turning redundant builds into free ones

☺ Like you're 10: If nothing about a piece of your project changed, the pipeline shouldn't have to rebuild it from scratch — it should just reuse what it already made last time.

Right-sizing controls the price of a minute; caching controls how many minutes you need in the first place, and for most pipelines it's the bigger lever. There are three layers worth caching, and mature pipelines use all three:

• Dependency caching — node_modules, a Python venv, a Maven .m2 or Gradle cache, keyed on a hash of the lockfile. Reinstalling unchanged dependencies on every run is the single most common source of pure waste in a CI pipeline, and it's usually the cheapest to fix.
• Docker layer caching — pulling a previous image as a --cache-from source, or BuildKit's inline and registry cache, so a container build only re-executes the layers whose inputs actually changed instead of rebuilding the whole image from the base layer up.
• Build-system remote caching — tools purpose-built for monorepos, like Bazel's remote cache, Gradle's build cache, Turborepo's remote cache, or Nx Cloud, key each individual build/test task's output on a content hash of its inputs. Touch one package in a hundred-package monorepo and only that package's tasks — plus whatever depends on it — actually run; the other ninety-nine are cache hits, restored instead of rebuilt.

# GitHub Actions dependency cache, keyed on the lockfile so a
# cache hit means "these exact dependencies were already installed."
- uses: actions/cache@v4
  with:
    path: ~/.npm
    key: npm-${{ runner.os }}-${{ hashFiles('package-lock.json') }}
    restore-keys: |
      npm-${{ runner.os }}-

# Docker BuildKit registry cache — pull the last image's layers
# as a cache source instead of rebuilding every layer cold.
- uses: docker/build-push-action@v6
  with:
    cache-from: type=registry,ref=registry.acme.io/app:buildcache
    cache-to: type=registry,ref=registry.acme.io/app:buildcache,mode=max

Treat cache hit rate as a first-class pipeline metric, reported on the same dashboard as build pass rate — a monorepo's remote cache sitting at 40% hit rate is telling you exactly as much as a flaky test suite is; something in the cache key is too broad (invalidating on changes that don't actually affect the output) or too narrow (missing a real dependency and technically correct but useless). The Scaling CI/CD Across Teams page goes further into remote-cache design for large monorepos; here, the point is narrower — every redundant build a cache prevents is runner-minutes that never get billed at all, which beats right-sizing them cheaper.

Per-team cost visibility for shared pipeline infrastructure

☺ Like you're 10: When twenty teams all push into the same shared build fleet, one invoice arrives for the whole fleet — and it takes real work to figure out whose pushes actually caused it.

This is the same shape of problem general cloud FinOps solves for a shared Kubernetes node — one bill, many tenants, no natural per-tenant line item — just one layer up the stack. A shared self-hosted runner pool, or a single org-wide GitHub Actions or GitLab CI/CD minutes quota, produces one aggregate number: this many runner-minutes, this many dollars, this month. It says nothing about which team's test suite, which repo's matrix, or which service's container builds actually consumed it, and "the pipeline is expensive" without a "because of whom" is not something anyone can act on.

Closing that gap starts with attribution, not a new tool. Tag every job with a team or cost-center label — a GitHub Actions runs-on label pool scoped per team, a GitLab CI job tags: field, or a Kubernetes namespace per team when self-hosted runners run on a cluster — and export usage against those labels. GitHub's Actions usage metrics and billing APIs, GitLab's CI/CD minutes usage reports (broken down per project and group), and self-hosted options like BuildBuddy's build analytics or a homemade export into Grafana all do the same underlying job: turn "the fleet cost $8,400 this month" into "payments spent $2,100, search spent $3,600, and $1,200 was genuinely shared CI infrastructure nobody should be blamed for." As with any billing feature, verify current export capabilities against your CI vendor's docs — this is an area where tooling has matured quickly and unevenly across GitHub, GitLab, and CircleCI.

Once teams can see their number, the same two allocation models general cloud FinOps uses apply here, and they trade off the same way. Showback — publishing each team's CI spend without moving any budget — is nearly always the right starting point: it creates awareness with no political cost, and it surfaces the inevitable attribution gaps (unlabeled shared workflows, a runner pool three teams quietly share) while nothing serious is riding on the number's accuracy. Chargeback — billing that spend against the team's actual budget — creates sharper accountability once the data is trusted, but it demands allocation accurate enough to survive an argument, because a chargeback number people don't believe just gets disputed instead of acted on.

The deployment-frequency vs. compute-spend trade-off

☺ Like you're 10: Shipping ten times more often is only "ten times more helpers, same total pizza" if you actually reuse the pizza that didn't change — otherwise it really is ten times the pizza.

This is where the DORA metrics and a delivery pipeline's cost curve intersect, and it's the connection most teams never make. Deployment frequency is one of DORA's four metrics, and elite performers deploy on-demand, multiple times a day. DORA's own finding — covered on that page — is that elite teams get both speed and stability from the same underlying practice: small, frequent, reversible changes, enabled by trunk-based development and heavy automated testing. What that page doesn't price in is the pipeline's own compute bill, and if your pipeline's design doesn't change alongside your deploy frequency, that bill scales close to linearly with it.

Here's the arithmetic. A team running one full pipeline a day — a 45-minute test suite on a 4-core runner, no caching, no selective testing — spends 45 runner-minutes daily. Move that same team to on-demand deploys, twenty a day, elite-tier by DORA's own benchmark, and a pipeline that still runs the full suite on every push spends 900 runner-minutes a day: a 20× throughput increase paid for with a 20× compute bill. Nothing about DORA's deployment-frequency metric objects to that outcome — the metric only measures how often you ship, never what each ship cost to build. That's a Goodhart's Law trap with a dollar sign on it, and it's the direct sibling of the gaming risk the DORA metrics page already warns about: a number chased without the underlying practice behind it stops being a good measure of anything.

The practices this page has already covered are exactly what breaks the 1-to-1 scaling. A small, trunk-based commit should only need to rebuild and retest the surface it actually touched — a cache hit on unaffected dependencies, a remote build cache skipping untouched packages, selective/impacted test targeting (the domain of Testing in the Pipeline) running only the tests a change could plausibly break. Model the same team with caching landing a realistic 70%+ hit rate and impacted-test selection trimming a typical small trunk commit's marginal run to about 8 minutes: the first run of the day still costs 45 cold minutes, but each of the next nineteen costs roughly 8, for a daily total near 197 runner-minutes — a 20× throughput increase for roughly a 4.4× compute increase, because the pipeline is finally exploiting the same "small, incremental change" property that makes frequent deploys safe in the first place.

Guardrails that keep the pipeline honest

☺ Like you're 10: A budget nobody checks isn't a budget — set a timer on every job, cancel the run that a newer push already made pointless, and save the expensive checks for the pushes that are actually about to ship.

The levers above compound; the guardrails below stop them from quietly eroding. Four are cheap enough to add to almost any pipeline this week:

• Job timeouts. A hung job with no timeout-minutes can bill for hours before anyone notices — set an explicit ceiling on every job, sized generously above its normal runtime but nowhere near "forever."
• Cancel superseded runs. A developer pushing three commits in ten minutes to the same PR doesn't need all three fully tested — only the last one. A concurrency group that cancels the in-progress run for a superseded commit reclaims that spend automatically.
• Path filtering. A documentation-only change doesn't need the full matrix, the container build, and the integration suite. Trigger the expensive stages only when the paths that actually matter changed, and reserve a fast, cheap check for everything else.
• Tiered pipelines. Run a fast, cheap check on every push to a branch, and gate the full, expensive suite — every matrix cell, every integration test — to merges into trunk or a scheduled nightly run. This is the cost version of the fail-fast ordering CI/CD pipelines already teaches for developer time; here it's the same ordering, applied to dollars instead of minutes-to-feedback.

# Cancel a superseded run the moment a newer commit lands on the
# same PR — and cap every job so a hang can't bill indefinitely.
concurrency:
  group: ci-${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

jobs:
  test:
    timeout-minutes: 20
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm test

All four guardrails share a spending-limit backstop worth setting regardless: GitHub Actions supports an org-level spending limit on top of included minutes, and GitLab lets you cap purchased CI/CD minutes per group — both exist specifically so a runaway matrix or an infinite retry loop hits a wall instead of an unbounded invoice. A budget that only shows up after the month closes is a postmortem; a budget enforced in the pipeline itself is a guardrail.