The State of DevOps 2026

The DORA four key metrics, the stubborn gap between elite and low performers, and how much of that gap is delivery infrastructure rather than culture.

Executive summary

DevOps performance is still best understood through DORA's four key metrics, and in 2026 the spread between the best and worst teams remains stubbornly wide. Elite performers deploy on demand, restore service in minutes, and keep change failure rates low; low performers batch releases, measure lead time in weeks, and spend recovery windows hunting for what broke. The metrics are simple, but the operational habits behind them are not evenly distributed across the industry.

What the data keeps surfacing is that two of the four metrics, lead time for changes and time to restore service, are heavily shaped by the inner loop of build and test. A pipeline that is slow, flaky, or queue-bound stretches lead time directly and slows the validation step during an incident. This report maps each DORA metric to the concrete pipeline behaviors that move it, and quantifies how much of the elite-versus-low gap is delivery infrastructure rather than culture alone.

The framing matters because the two halves of the gap respond to very different interventions. The cultural half, how teams collaborate, how they handle blame, how they batch work, is real but slow and hard to move. The infrastructure half, the queue, the cold start, the transient flake on the critical path, is mechanical and fast to move. Conflating the two leads teams to attempt a culture change when an infrastructure change would have delivered most of the benefit in a fraction of the time.

DORA's bands have held up remarkably well as a benchmark precisely because they measure outcomes rather than practices, so they stay meaningful as tooling and fashion shift around them. This report uses those published bands as the spine and asks a narrower question on top of them: of the distance between an elite team and a low one, how much is the pipeline, and what does closing that specific portion actually require.

The encouraging finding is that the infrastructure half of the gap is the cheaper half to close. Reliable, fast CI does not require reorganizing teams or rewriting how they work; it requires removing the queue, the cold start, and the transient flake from the critical path. That is a weeks-long infrastructure project rather than a years-long cultural one, which makes it the rational place for most teams to start.

The elite-vs-low gap is widest on the two flow metrics

Deployment frequency and lead time for changes show the largest spread between bands, and both are throttled by the build-test inner loop more than by any single cultural factor. The chart below puts elite deployment frequency far above the lower tiers, and DORA's published bands describe that elite cadence as on-demand (multiple per day) against the batched, infrequent releases of low performers. The distance between those two is enormous, and most of it runs through the pipeline.

Teams that deploy on demand have made the cost of a single change trivially small. Shipping is a button, the pipeline is fast, and the path to production is short enough that releasing often is the path of least resistance. Teams that batch have an expensive, slow path to production that they understandably traverse rarely, because each release is a project rather than a routine. The cadence difference is downstream of the path difference.

Shrinking the path is the lever, and the path is largely pipeline. A team cannot reasonably deploy on demand if every deploy waits on a slow, flaky validation, so the cadence ceiling is set by the pipeline before culture even enters the picture. This is why the two flow metrics are the ones most responsive to an infrastructure change: they are gated by the speed and reliability of the inner loop.

Waiting on CI is a measurable tax on lead time

In a typical mid-size pipeline, close to a quarter of end-to-end lead time is spent waiting on builds and tests rather than producing or reviewing code. The chart below breaks lead time into coding and review, waiting on CI, manual QA, and deploy, and the waiting-on-CI wedge is a substantial and often surprising share of the total. It is time the change is finished but not yet validated, sitting idle in a queue.

Much of that wait is queue time and cold starts rather than useful work. A job that waits two minutes for a runner to become available and another minute for a cold cache to warm has spent three minutes producing nothing, on every run, before the first useful test executes. Across a team and a month those non-productive minutes compound into a meaningful fraction of lead time that no one is choosing to spend.

Managed runners that scale instantly and auto-heal transient failures convert that waiting directly into shorter lead time without any change to how the team writes software. Removing the queue removes the wait; removing the cold start removes the warmup; removing the transient flake removes the re-run. Each of those is a slice of the lead-time pie that disappears with an infrastructure change rather than a process change, which is what makes it attractive.

Change failure rate is a quality signal, not a speed penalty

A persistent myth is that deploying more often means breaking more often. The data shows the opposite: elite performers combine the highest deployment frequency with the lowest change failure rate. The chart below makes the inverse relationship plain, with change failure rate falling tier by tier even as deployment frequency rises, which is the exact opposite of what the speed-versus-safety tradeoff would predict.

The reason is batch size. Small, frequently shipped changes are easier to test, review, and reason about than large batched ones, so they fail less often and are easier to diagnose when they do. A one-line change has a tiny surface for failure; a month of accumulated change has an enormous one. Frequent shipping is not reckless, it is the discipline that keeps each change small enough to be safe.

Fast, reliable CI is what makes the small-batch discipline affordable. Shipping small and often is only sustainable if running the pipeline on each change is cheap and quick, otherwise the per-change overhead pushes teams back toward batching. The pipeline is therefore the enabling condition for the very practice that drives change failure rate down, which is why the quality metric and the speed metric improve together rather than trading off.

• Elite performers pair the highest deployment frequency with the lowest change failure rate, inverting the assumed speed-versus-safety tradeoff.
• Small batches fail less often and are easier to diagnose, because each change has a tiny surface for failure.
• Fast, cheap CI is the enabling condition for small-batch shipping; a slow pipeline pushes teams back toward risky batching.

Time to restore is half detection, half validation

Recovery time decomposes into noticing the problem and shipping the fix, and the second half runs straight through CI. The chart below shows elite restore times under an hour against days for low performers, and that gap is not purely about observability. Even a team that detects an incident instantly still has to build, test, and ship the fix or the rollback, and that second half is gated by the pipeline.

When the pipeline that validates a rollback or a hotfix is slow or flaky, MTTR inflates at the worst possible moment. A transient failure on the fix pipeline during an active incident is uniquely costly: it delays recovery while the team is already under pressure, and it can send responders chasing a phantom problem in a fix that was actually correct. The pipeline's reliability under pressure is part of the incident response, not separate from it.

Elite restore times under an hour depend on a pipeline that is trustworthy under pressure, not just on good observability. Less than one hour is the published elite band, and hitting it requires that the validation half of recovery be fast and dependable, because no amount of rapid detection helps if shipping the fix then waits on a slow or flaky build. The fastest responders have invested in both halves, and the validation half is the one the pipeline owns.

Pipeline wait is also the developer-experience tax behind the metrics

The lead-time wait that shows up in the DORA breakdown is the same wait developers experience as a daily friction. Because 76 percent of professional developers depend on CI/CD in their daily flow, pipeline wait time ranks among the top recurring frictions they report, sitting near unclear requirements and flaky tests at the top of the list. The metric and the lived experience are two views of one phenomenon.

This matters because it means the infrastructure investment pays off twice. Shortening CI wait reduces the lead-time tax that shows up in the DORA numbers, and it simultaneously removes the daily friction that fragments developer focus and erodes flow. A team is not choosing between better delivery metrics and a better developer experience; the same fast, reliable pipeline delivers both at once.

It also explains why the two stories keep converging. The pipeline that produces elite lead time is the pipeline that keeps developers in flow, because both depend on a short, trustworthy loop from push to green. Treating delivery performance and developer experience as separate initiatives misses that they share a root cause and a fix, and that the fix is largely the runner layer underneath both.

Closing the infrastructure half of the gap is the cheap win

The delivery-performance gap has a cultural half and an infrastructure half. The cultural half, collaboration, blamelessness, batch discipline, is real but slow to move, often taking years and surviving reorganizations and leadership changes. It is worth doing, but it is not where a team gets its first fast result, and treating it as the only lever leaves the easier win on the table.

The infrastructure half, queueless capacity, aggressive caching, automated recovery from transient flake, right-sized runners, can be adopted in weeks and moves lead time and MTTR immediately. None of it requires changing how the team collaborates or how it handles incidents culturally; it changes the machinery underneath, and the metrics respond because that machinery sits directly on the critical path of two of the four DORA measures.

Latchkey managed runners target exactly this half, at roughly 70 percent below GitHub-hosted compute. Removing the queue shortens lead time, faster provisioning shortens the validation half of MTTR, and self-healing removes the transient flake that inflates both at the worst moments. For a team trying to move up the DORA bands, this is the portion of the gap that yields first and cheapest, which makes it the rational starting point even for teams committed to the longer cultural work.

• The cultural half of the gap is real but slow, often taking years and surviving reorganizations.
• The infrastructure half (queueless capacity, caching, auto-recovery, right-sized runners) moves lead time and MTTR in weeks.
• Managed self-healing runners attack the infrastructure half directly, at roughly 70 percent below GitHub-hosted rates.

The four metrics move together when the pipeline improves

One of the most useful findings in DORA's research is that the four metrics are not in tension; elite teams are elite on all of them at once. This is counterintuitive only if you assume speed trades against stability, and the data has consistently shown it does not. The metrics cluster because they share underlying enablers, and a fast, reliable pipeline is one of the largest shared enablers.

Improving the pipeline tends to move all four in the same direction. Shorter validation shortens lead time and MTTR; cheaper, faster runs make small-batch shipping affordable, which raises deployment frequency and lowers change failure rate. A single infrastructure investment touches every one of the four metrics, which is rare and is what makes the pipeline such a high-leverage place to spend effort.

This is why a team should be suspicious of interventions that promise to move one DORA metric in isolation. The metrics are entangled, and the durable improvements are the ones that improve the shared enablers underneath them. The pipeline is the most accessible of those shared enablers, which is the practical case for starting a DevOps improvement program at the runner layer rather than at the org chart.

Recommendations

Separate the cultural gap from the infrastructure gap, then start with infrastructure

Of the distance between a low and an elite team, part is culture and part is machinery. The cultural half is real but slow; the infrastructure half moves in weeks. Diagnose which portion of your lead time and MTTR is queue, cold start, and transient flake, and close that first, because it yields the fastest movement up the DORA bands.

Treat pipeline wait as lead time, because it is

Close to a quarter of lead time in a typical mid-size pipeline is spent waiting on CI, much of it queue and cold-start time producing nothing. Measure that wedge explicitly and attack it as lead time rather than as a separate infrastructure concern, since it is a direct and measurable component of the DORA flow metric.

Ship small and often to drive change failure rate down

Elite performers pair the highest deployment frequency with the lowest change failure rate because small batches fail less and diagnose faster. Make the pipeline fast and cheap enough that running it per small change is painless, which is the enabling condition that makes the small-batch discipline sustainable rather than aspirational.

Make the fix pipeline trustworthy under pressure

Half of time-to-restore runs through CI, and a flaky fix pipeline inflates MTTR at the worst possible moment, during an active incident. Ensure the rollback and hotfix path is fast and self-healing so the validation half of recovery is dependable when it matters most, not just on a calm day.

Invest at the runner layer to move all four metrics at once

The four DORA metrics cluster because they share enablers, and a fast, reliable pipeline is one of the largest. Managed, self-healing runners that scale instantly and recover transient failures move lead time, MTTR, deployment frequency, and change failure rate together, at roughly 70 percent below GitHub-hosted compute.

Outlook

Expect the elite-versus-low gap to stay wide through 2026 and into 2027, but expect more teams to close the infrastructure half of it quickly as managed, self-healing runners make queueless capacity and automated recovery a baseline rather than a project. The cultural half will keep moving slowly, as it always has, but the mechanical half is increasingly a solved problem that any team can adopt without reorganizing, which should compress the lower tail of the distribution over time.

DORA's four metrics will remain the durable benchmark precisely because they measure outcomes rather than practices, so they stay meaningful as tooling fashions come and go. What is changing is the growing recognition that a large, specific portion of the gap between bands is delivery infrastructure on the critical path, and that this portion has a fast, well-understood fix. That recognition is what turns the metrics from a scoreboard into an actionable roadmap.

For most teams the practical takeaway is to start where the movement is cheapest. The pipeline sits on the critical path of two of the four metrics and shares enablers with the other two, so improving it moves all four at once, in weeks rather than years, and without a reorganization. The organizations that internalize that will climb the DORA bands by fixing their machinery first while their peers wait on a cultural transformation to deliver what an infrastructure change would have delivered sooner.

Methodology

This report synthesizes DORA's publicly published performance bands for the four key metrics with Latchkey's own analysis of CI/CD runner economics and pipeline timing. The DORA elite, high, medium, and low bands are public benchmarks and are attributed to DORA. The 76 percent CI adoption figure reflects the Stack Overflow Developer Survey. Figures labeled "modeled" are illustrative estimates derived from typical pipeline shapes and published pricing, not a primary survey. Per-tier numbers are representative midpoints chosen to illustrate the bands, not exact survey medians, and should be verified against the current DORA report. 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.

Sources

• DORA State of DevOps Report
• Stack Overflow Developer Survey
• GitHub - Octoverse
• CNCF Annual Survey

More Latchkey reports