Low DevOps performers fail 40% of changes; elite teams fail 5%

01The benefit, measured: four numbers separate elite from low

DORA measures software delivery with four keys: how often a team deploys, how long a change takes from commit to production, what share of changes fail, and how fast the team recovers from a failed deployment. In its 2024 report, elite teams deploy on demand, take less than a day per change, fail 5% of changes and recover in under an hour. Low performers deploy between once a month and once every six months, take one to six months per change, fail 40% and take a week to a month to recover. Elite teams are under a fifth of organisations.¹

The benefit the original promised, “faster time to market” with “quality improvement”, is therefore true only for the teams that get both. The four keys are cheap to measure from the systems a large enterprise already runs: the deployment log, the change calendar and the incident tool. Measure them before the programme starts, or you will never know which cluster you moved from.

Large enterprises usually find their lead time is set not by engineering but by approval. A change advisory board that meets weekly puts a floor of days under every change, however fast the pipeline is. The answer is not to abolish the board, which an auditor will ask about, but to move routine, tested, reversible changes to a standard-change path with automated evidence, and keep the board for the changes that genuinely need judgement. That is the original’s “organisational culture” challenge in a form a risk committee can sign.

02AI made developers feel faster and delivery less stable

In the 2024 report, more than 75% of respondents relied on AI for at least one daily task. DORA estimated that a 25% increase in AI adoption went with a 7.5% rise in documentation quality, 3.4% in code quality and 3.1% in code review speed, and with a 1.5% fall in delivery throughput and a 7.2% fall in delivery stability. 39% reported little or no trust in AI-generated code.²

The 2025 report, published on 24 September 2025 from nearly 5,000 respondents, moved one of those lines. AI use reached 90%, more than 80% said it had raised their productivity, and the share with little or no trust in AI code fell to 30%. AI adoption now showed a positive relationship with throughput, but the relationship with delivery stability was still negative.³ DORA’s 2025 report frames AI as an amplifier of whatever a team already is: fast feedback and small batches get faster, weak testing and large batches break more often.

03Platforms: 90% have one, and the first year can cost performance

The original’s answer to scale was “start small” and “build a strong team”. DORA’s answer is the internal developer platform: a paved road of templates, pipelines and environments that product teams use on their own. In 2024 DORA found platforms raise developer productivity, are more common in larger organisations, and can bring a temporary dip in performance before the gains arrive; results depend on treating the platform as a product with its developers as users.² By 2025, 90% of organisations had adopted at least one platform.³

Legacy systems, the original’s second challenge, belong in step one. A mainframe or a vendor-hosted core system with a monthly release window is a fixed constraint on the value stream. Measure it honestly and decouple around it, rather than counting it as a failure of the programme.

04The toolchain bill: three meters, and a quarter of products quote only

A DevOps programme buys a toolchain, and a large enterprise discovers the meters only at renewal. TechBag’s developer tools guide, last reviewed on 24 August 2026, lists 28 products by SKU across nine vendors: GitHub, GitLab, Atlassian, Postman, HashiCorp, JFrog, Sonar, Sonatype and Kong.⁴

The meters matter because they move with the success of the programme. More deployments mean more CI minutes; more infrastructure as code means more managed resources on a per-resource meter; a wider AI rollout means more add-on seats. Budget the second year at the deployment rate you are aiming for, not the one you have.

The usual escape from the minutes meter is self-hosted runners: build machines you already own, registered with GitHub or GitLab, so the pipeline stops consuming metered minutes. The guide is blunt about the trade: they are infrastructure you now maintain and secure, and a compromised runner is a supply-chain problem, because it holds the credentials every deployment uses.⁴ For a large enterprise with a data centre and a security team that is often the right trade. For a business unit without either, the meter is cheaper than the incident.