How DORA Metrics Are Redefining What High Performance Looks Like in Software Engineering

For years, engineering teams measured performance through outputs: features shipped, bugs closed, sprint velocity maintained. DORA metrics have replaced that approach with something more meaningful. Developed by the DevOps Research and Assessment program and backed by over a decade of research across thousands of engineering organisations, they measure not what teams produce, but how reliably and quickly they deliver it.

The shift matters because output metrics can look healthy while delivery performance quietly deteriorates. A team can close tickets consistently and still struggle with production incidents, long release cycles, and slow recovery times. DORA metrics surface those problems directly, which is why they've become the most widely adopted engineering performance framework in the industry.

What DORA Metrics Measure

DORA metrics evaluate software delivery performance across five dimensions that together capture both speed and stability. They are Deployment Frequency, Lead Time for Changes, Change Failure Rate, Failed Deployment Recovery Time, and Deployment Rework Rate.

Deployment Frequency measures how often a team successfully deploys code to production. Higher frequency indicates a more responsive, lower-risk delivery process.

Lead Time for Changes tracks the time from a code commit to its deployment in production. Shorter lead times reflect a more efficient pipeline with fewer bottlenecks.

Change Failure Rate captures the percentage of deployments that cause a production failure requiring remediation. It is the most direct indicator of release reliability.

Failed Deployment Recovery Time measures the average time taken to restore service following a production failure caused by a software change. It reflects incident response capability and system resilience.

Deployment Rework Rate, added to the framework in 2024, measures the ratio of unplanned deployments triggered by production incidents. It captures the hidden rework cost of unstable releases.

Together, these five metrics give engineering leadership a complete picture of delivery performance, one that shows both how fast a team moves and how much that speed costs in stability.

What the Current Data Reveals

The 2025 State of AI-Assisted Software Development report from dora.dev, based on surveys from nearly 5,000 technology professionals, produced benchmark data that reveals how wide the performance gap is across the industry.
On Deployment Frequency, only 16.2% of organisations achieve on-demand deployment, meaning multiple deployments per day. At the other end, 23.9% deploy less than once per month. That gap represents a fundamental difference in how teams manage risk and respond to change.

On Lead Time for Changes, just 9.4% of teams achieve lead times under one hour. Meanwhile 43.5% need more than one week to move a commit from development to production. In environments where business conditions shift quickly, lead times measured in weeks create a structural lag that compounds over time.

On Change Failure Rate, only 8.5% of teams achieve a rate of 0-2%. Nearly 40% experience failure rates above 16%, meaning more than one in six deployments requires remediation after reaching production. For Global 2000 companies, where production downtime costs an average of $15,000 per minute according to the Splunk and Cisco Hidden Costs of Downtime 2026 report, that rate of instability carries significant financial consequences.

Why Speed and Stability Are Not Trade-offs

One of the most important and counterintuitive findings from DORA's research is that speed and stability are not competing priorities. Teams that deploy most frequently also tend to have the lowest change failure rates and the fastest recovery times. They achieve better outcomes across all five metrics simultaneously rather than optimising one at the expense of another.
The reason is structural. Teams that ship frequently do so in smaller batches.

Smaller changes are easier to test, easier to roll back, and easier to debug when something goes wrong. The discipline required to deploy confidently at high frequency forces investment in the practices that improve stability, including automated testing, observational tooling, and clear deployment gates.

Teams that deploy infrequently tend to batch large changes together. The blast radius of each deployment is larger, failures are harder to isolate, and recovery takes longer. Infrequent deployment does not reduce risk. It concentrates it.

The Role of Test Coverage in DORA Performance

Change Failure Rate and Deployment Rework Rate are the two metrics most directly influenced by the quality of pre-production validation. When teams ship changes without adequate test coverage, failures that automated testing would have caught reach production instead. Each failure drives up the change failure rate, triggers recovery work that affects failed deployment recovery time, and in cases where a hotfix deployment is required, counts against deployment rework rate as well.

The connection between test coverage and DORA performance is measurable, and it explains why investment in automated testing tends to show up as improvement across stability metrics within months. Platforms like Keploy address this by capturing real API interactions during development and converting them into test cases automatically, building coverage from actual system behaviour rather than manually authored scripts. For teams whose change failure rates reflect inadequate API and integration test coverage, this approach closes the gap at the source.

How Engineering Leaders Are Using DORA Metrics

The most effective uses of DORA metrics in engineering organisations share a common characteristic: the data drives action rather than sitting in a dashboard. Teams that see consistent improvement tend to follow a structured approach.
They start by establishing a baseline across all five metrics. A single metric in isolation is rarely diagnostic. Change Failure Rate without Deployment Frequency context, for instance, can be misleading since teams that deploy infrequently often show lower failure rates simply because they batch changes and deploy less often.

They review metrics on a quarterly cadence. Frequent enough to catch regressions early, but spaced enough to see the impact of changes made in the previous cycle.

They identify which metric is the primary constraint and direct investment there. For many teams that constraint is Change Failure Rate, which points toward testing coverage and deployment automation as the priority intervention.
They treat metric improvements as signals, not targets. Teams that optimise metrics directly, rather than the underlying practices that drive them, tend to move numbers temporarily without building lasting performance improvements.

What High Performance Actually Looks Like

In 2025, DORA moved away from categorising teams into fixed performance tiers and toward a percentile distribution model that reflects the full range of team contexts. A team deploying weekly in a highly regulated financial services environment may be performing well above its industry peers, while the same frequency in a consumer SaaS company signals underperformance.

High performance, in DORA's framework, means performing well across all five metrics relative to your context, with trajectory as important as absolute numbers. Teams that consistently improve their Lead Time for Changes while maintaining a stable Change Failure Rate are building the delivery capability that DORA research consistently links to better organisational outcomes, including higher employee satisfaction and stronger business performance. The metrics don't define high performance. They make it visible.

Learn more about the benchmarks, tools & strategies to improve DORA metrics:
https://keploy.io/blog/community/how-to-improve-dora-metrics

3rd Floor, 613, 1st Main Rd, Sector 6, HSR Layout, Bengaluru, Karnataka

Keploy is an AI-powered testing tool that specializes in creating test cases and generating stubs/mocks for end-to-end testing. It can achieve an impressive 90% test coverage in just a matter of minutes using open-source testing resources. Keploy offers several notable features, including a straightforward Integration Framework for incorporating new libraries, the ability to convert API calls into test cases and data mocks, and the capability to handle a wide range of detailed test cases. Additionally, it supports four programming languages: Java, Node.js, Python, and Go.

This release was published on openPR.