The State of CI/CD Metrics 2026
Almost every team runs a pipeline, far fewer measure one, and the metrics that go uninstrumented are exactly the ones that explain where the time and money go.
Executive summary
Almost every professional team runs CI in 2026, but running a pipeline and measuring one are very different maturity levels. The data shows a long tail of teams whose entire pipeline telemetry is a green or red check, with no durable record of duration, cost, flakiness, or queue time to reason about. The pipeline works, in the narrow sense that it can block a bad merge, but it is opaque in every other sense that matters to the people paying for it and waiting on it.
The metrics that are tracked cluster around outcomes the whole organization already cares about: deployment frequency, success rate, and lead time, because those map cleanly onto the DORA framework that leadership reads. The metrics that go missing are the operational ones that explain those outcomes. Where the minutes are spent, how often runs are re-run, how long jobs wait in queue, and what each pipeline costs are precisely the signals that stay dark, and that darkness is where regressions hide until they surface on the invoice or in a wave of developer complaints.
This report quantifies the gap between what teams track and what would change a decision. We look at which KPIs are durable trended signals rather than glances, how the population splits by instrumentation depth, where teams land on the DORA bands, and which currently-missing metric most often changes the next pipeline decision once a team finally collects it. The recurring pattern is that the highest-value signals are not the ones being watched.
Three numbers frame the year. Roughly three quarters of professional developers report using CI/CD, but only a minority instrument it past pass or fail. Under a third of teams track per-pipeline cost as a first-class metric, even though cost ranks first on modeled decision value among the signals teams are missing. And the DORA elite band, a change failure rate of 0-15% with recovery in less than one hour, is tracked far more often than the operational drivers that actually move a team into it.
The encouraging part for engineering leaders is that closing the gap is cheap. The teams that have closed it did not buy a sprawling observability suite and stare at it; they instrumented the three or four signals that change a decision, namely flaky rate, queue time, and per-pipeline cost, and tied them back to the DORA outcomes leadership already reads. The instrumentation is mostly a property of the runner layer rather than a project the team has to staff, which is what makes it achievable without a platform team.
Modeled adoption of common CI/CD metrics as durable, trended signals rather than one-off glances. · Source: Latchkey analysis (modeled)
Modeled split of teams by how deeply they instrument their pipelines beyond pass or fail. · Source: Latchkey analysis (modeled)
Email me the report
The full report is right here on this page, free. Want the link in your inbox to read later or share, plus new Latchkey reports as they drop? Drop your email and we will send it over.
Sent! Check your inbox for the report link.
No spam. Unsubscribe anytime.
Most pipelines are observed only as pass or fail
The single most common state of CI instrumentation is a binary check with no durable history behind it. The pipeline ran, it went green or red, and that result was enough to merge a pull request or block it. Nothing about that signal survives the run. There is no record of how long it took, which job consumed the minutes, whether the same step has been failing intermittently for a week, or how the whole thing trends across the last thousand invocations.
That is a perfectly adequate state for the narrow job of gating a merge, and it is why so many teams stop there. The problem is that everything else a team would want to know about its pipeline is invisible at this level. A build that has crept from four minutes to eighteen over two years shows up as green every single time, so the regression is real but unobserved. The cost of that slowdown is paid by every developer who waits on it, but it never appears as a number anyone can point at.
The modeled split of the population is stark. A large share of teams sit at pass or fail only, a comparable share have trended duration and success but nothing deeper, and only a small slice collect the cost, flake, and queue telemetry that would let them reason about the pipeline as a system. A residual group keep no durable metrics at all. The shape of that distribution, not any single number in it, is the story of CI metrics in 2026.
- A binary check gates merges but preserves no history, so trends are structurally invisible.
- A slow drift in build duration reads as green on every run and is never surfaced as a regression.
- Only a small minority of teams collect cost, flake, and queue telemetry together.
Cost is the highest-value metric teams are not tracking
Per-pipeline cost is tracked by under a third of teams, which makes it one of the least-instrumented signals in CI. Yet when it is instrumented, it changes a decision more often than any other previously-missing metric in our modeling. That inversion, low adoption paired with the highest decision value, is the single most actionable finding in this report.
The reason cost is so decision-changing is that it makes mechanical waste legible at the level where someone can act on it. Without a per-pipeline cost number, an expensive macOS leg that runs work which would pass identically on Linux is invisible. An oversized runner that bills for cores the job never touches is invisible. The minutes burned re-running flaky failures are invisible. All of these are real line items, but they are spread across a bill that nobody attributes back to a specific pipeline, so nobody fixes them.
Teams that turn cost on tend to act within a week. The first time a leader sees that one cross-platform workflow is responsible for a disproportionate share of the bill, the conversation about reshaping it happens immediately, because the number is concrete and the fix is well understood. The chart of modeled decision value puts per-pipeline cost at the top for exactly this reason: it is the metric most likely to be both newly visible and immediately actionable.
How often instrumenting a currently-missing metric changed a team's next pipeline decision, modeled. · Source: Latchkey analysis (modeled)
DORA outcomes are tracked, but their drivers are not
Deployment frequency, lead time, and change failure rate get measured because they map to the DORA framework leadership already reads. Elite is defined by a change failure rate of 0-15% and recovery in less than one hour, deployment on demand, and a lead time under a day, and those four bands are the lingua franca executives use to talk about delivery. So teams instrument them, because the audience for them exists.
The trouble is that DORA metrics are outcomes, and outcomes are downstream of operational behavior that mostly goes unmeasured. Change failure rate is moved by flakiness and by how reliably the pipeline catches real defects. Lead time is moved by build duration and queue time. Recovery time is moved by how fast a pipeline can re-validate a fix. A team that tracks the four DORA numbers but not flake rate, duration, or queue time can see its score without seeing a single one of the levers that determine it.
This is why the DORA band distribution tells only half of one story. Plenty of teams can report which band they are in, and the modeled spread across elite, high, medium, and low is real. Far fewer can explain why they sit where they do, or change it on purpose, because the drivers sit in the operational layer they never instrumented. Measuring the outcome without the driver is like watching the scoreboard with the field blacked out.
Modeled distribution of teams across the DORA performance bands. · Source: Latchkey analysis (modeled), DORA bands
Flaky-test rate is the cheapest high-value signal to add
Flakiness is tracked by only about a third of teams, which is surprising given how cleanly it can be measured. Every re-run leaves a machine-readable trace: the same commit, the same job, a red result followed by a green one with no code change in between. The raw material for a flaky-rate metric already exists in the run history of essentially every pipeline. Almost nobody aggregates it.
Surfacing flaky rate as a trended number is low-effort instrumentation with an outsized payoff. It immediately exposes a recurring tax that is otherwise diffuse and deniable, the minutes spent on re-runs and the engineer context switches when a green change comes back red for no reason. A team that cannot see its flake rate tends to treat each flake as a one-off annoyance; a team that watches the trend treats it as a budget line and a regression signal.
Flaky rate is also a prerequisite for the next decision rather than an end in itself. You cannot sensibly decide whether automated recovery is worth turning on, or whether a particular job needs quarantining, until you can see how much flakiness is actually costing and where it concentrates. That makes flake rate the natural first metric to add for a team moving past pass or fail, because it is cheap to collect and it unlocks the decisions that follow.
Queue time is the developer-experience metric nobody graphs
Queue time, the gap between a job being requested and a runner picking it up, is among the least-tracked signals in CI, sitting near the bottom of the KPI adoption chart. It is also one of the most directly felt. A developer does not experience a pipeline as a cost line; they experience it as a wait, and queue time is a large and growing part of that wait under any kind of burst load.
The reason it goes unmeasured is partly that it is invisible in the default tooling. A provider status page shows a job as running or done, not as having waited ninety seconds for capacity. Unless a team deliberately captures the queue-to-start interval, the wait disappears into the overall wall-clock time and gets blamed on the tests rather than on capacity that was not ready.
Queue time earns its place on the decision-value chart because it points at a specific, fixable cause. A rising queue trend is a capacity-readiness problem, and the fix is warm capacity or better autoscaling rather than faster tests. A team that cannot see queue time will keep trying to speed up tests that are not the bottleneck, while the actual delay sits in a metric they never collected.
Self-healing runners turn flake telemetry into an action
Once a team measures its flaky rate, the obvious next question is what to do about transient failures. Measuring the tax does not pay it back; it just makes it visible. The action that follows is automated recovery for the mechanical, transient failures that make up the bulk of flakes: registry timeouts, network blips, out-of-memory kills on undersized runners, and races that pass on a clean retry.
Self-healing managed runners attack exactly that category. When a step fails on a known-transient signal, the platform retries it on a fresh environment automatically, before a human ever sees a red check. The flake metric drops without anyone touching test code, because most of what it was counting was never broken test logic in the first place, it was the environment hiccuping. The minutes spent become recovery minutes rather than wasted ones.
The same runner layer that performs the recovery is also the natural place to emit the metrics this report says teams are missing. A runner that retries a transient failure already knows it happened, so it can emit a recovery event. A runner that provisions per job already knows the queue-to-start interval and the per-job duration. The cost, flake, and queue telemetry that most CI-using teams currently lack is a byproduct of the runner doing its job, not a separate instrumentation effort, which is what makes it cheap to obtain.
- Most flakes are mechanical and pass on a clean retry, so recovery removes them without test changes.
- A self-healing runner emits recovery events as a byproduct, turning flake rate into a live metric.
- Per-job duration and queue-to-start time fall out of a per-job runner for free.
The teams that close the gap instrument decisions, not dashboards
The teams that have moved past pass or fail did not do it by buying the largest observability platform and pointing it at CI. They did it by asking a sharper question: which signal, if we could see it, would change what we do next? That question filters a long list of possible metrics down to the few that actually matter, and it keeps the effort proportional to the payoff.
In practice the answer is almost always the same short list. Flaky rate, because it exposes a recurring tax and gates the recovery decision. Queue time, because it explains a wait developers feel and points at a capacity fix. Per-pipeline cost, because it makes mechanical waste legible to the people who pay for it. Tie those three back to the DORA outcomes leadership already tracks, and the operational view and the executive view finally describe the same pipeline.
What distinguishes these teams is that they treat the metrics as triggers for action rather than decoration. A flake-rate regression opens a ticket. A queue-time trend prompts a capacity change. A cost spike on one pipeline gets it reshaped. Because the metrics are wired to decisions, they stay alive and trusted, instead of becoming the dashboard everyone stopped looking at three months after it was built.
Recommendations
Instrument the four DORA metrics plus cost per merge
Track deployment frequency, lead time, change failure rate, and time to restore, and add CI cost per merge so the finance view and the engineering view agree on one number. The DORA four give leadership the score it already reads; cost per merge gives engineering the lever that moves the bill. Without the cost line, a pipeline budget is a number nobody can defend because nobody can see it.
Add flaky-test rate before anything else
Flake rate is the cheapest high-value signal to collect, because every re-run already leaves a machine-readable trace. Surface it as a trended metric, watch it the way you watch test coverage, and use it to decide whether automated recovery is worth turning on. It is the natural first step out of pass-or-fail-only instrumentation.
Capture queue-to-start time, not just wall-clock
Separate the time a job spends waiting for a runner from the time it spends doing work. A rising queue trend is a capacity-readiness problem with a capacity fix, and it is invisible in the default provider UI. Teams that cannot see queue time keep optimizing tests that are not the bottleneck.
Tie operational signals to the DORA outcome they drive
Do not present flake rate, duration, and queue time as a separate engineering dashboard. Connect each to the DORA outcome it moves: flakiness to change failure rate, duration and queue time to lead time, recovery speed to time to restore. When the driver sits next to the outcome, leadership and engineering reason about the same pipeline.
Let the runner emit the telemetry rather than retrofitting it
Recovery events, per-job duration, and queue-to-start time are byproducts of a per-job, self-healing runner, not a separate instrumentation project. Choosing a runner layer that emits them by default turns observability from work you have to staff into a property you already have, and it is part of why Latchkey targets roughly 70% below GitHub-hosted rates while surfacing this signal for free.
Outlook
Expect the instrumentation gap to become a competitive divide rather than a curiosity through 2026 and into 2027. The teams that can see flake rate, queue time, and cost per merge will keep tightening those numbers, which compounds into faster delivery and lower spend, while the teams stuck at pass or fail will keep paying for regressions they cannot see. The metrics do not just describe the gap; collecting them is what closes it.
The likeliest direction of travel is that this telemetry stops being something teams build and starts being something they receive. As more CI compute moves to runner layers that emit recovery, duration, and queue signal by default, the cost of getting to production-grade pipeline observability drops toward zero, and the teams still hand-rolling it will find the effort harder to justify against a platform that includes it.
For most teams the practical takeaway is narrow and achievable. CI metrics do not require a heroic observability program; they require picking the three or four signals that change a decision, wiring them to the DORA outcomes leadership already tracks, and sourcing them from a runner layer that produces them as a byproduct. The organizations that do this will spend the next two years steering their pipelines on purpose while their peers keep reading a single green check.
Methodology
This report combines publicly available DevOps research, namely developer surveys and the DORA State of DevOps program for the performance bands, with Latchkey's modeled estimates of metric adoption and decision value across typical engineering orgs. Adoption and decision-value percentages are illustrative and will vary with team size, tooling, and the maturity of an org's observability practice; the DORA band definitions are used verbatim from the published program. Figures labeled "modeled" are illustrative estimates derived from public pricing and typical pipeline shapes, not a primary survey; figures attributed to a named source reflect that source. Pricing reflects published rates at time of writing and should be verified against current provider pricing.