What Are DORA Metrics? The Five Measures, Benchmarks and Common Misuse

DORA metrics are the measures of software delivery performance defined by DORA, the DevOps Research and Assessment program run by Google Cloud. Since 2024 there are five: change lead time, deployment frequency and failed deployment recovery time, which measure throughput, and change fail rate and deployment rework rate, which measure instability.

Many articles still describe four keys, and many name reliability as the fifth. Both are out of date. The definitions below follow DORA's own metrics guide, last updated January 5, 2026.

What are the five DORA metrics?

The five DORA metrics are change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate. DORA groups the first three as throughput, meaning how many changes move through the system over time, and the last two as instability, meaning how well deployments go. Together they summarize delivery performance for one application or service.

Where do DORA metrics come from?

DORA metrics come from DORA's survey research, which began with a 2014 study that set out to link IT performance to organizational performance scientifically. The program is now run by Google Cloud, and its 2024 Accelerate State of DevOps Report was its tenth. The 2025 edition was renamed the State of AI-assisted Software Development.

The research reached many engineering teams through Accelerate, the 2018 book by Nicole Forsgren, Jez Humble and Gene Kim. A central finding dates from 2015: speed and stability are not a trade-off. In every 2024 performance cluster, throughput and stability were correlated.

Is reliability the fifth DORA metric?

No. Reliability is not the fifth DORA metric, although DORA's 2021 report called it that. DORA's own history of the metrics says the label was inaccurate, because reliability measures operational performance rather than software delivery performance. The actual fifth metric is deployment rework rate, which DORA added in 2024.

Reliability still matters in DORA's model. It grew out of availability, which DORA added in 2018, and broadly covers latency, performance and scalability as well as uptime. Teams usually express reliability targets as service level objectives; see What Is an SLO?

How has the set of DORA metrics changed?

The set of DORA metrics grew from four measures in 2014 to five in 2024. Along the way the measures were split into throughput and stability, availability and then reliability were added as operational measures, mean time to recover became failed deployment recovery time, and deployment rework rate joined the set.

The history of the metrics that DORA published in January 2026 records each change:

• 2014: the research starts with four candidate measures: deployment frequency, lead time for changes, mean time to recover and change fail rate.
• 2015: the measures are grouped into throughput and stability.
• 2018: availability is added as a measure of operational performance.
• 2021: availability broadens into reliability.
• 2023: mean time to recover, also called time to restore service, is renamed and redefined as failed deployment recovery time. It now counts only failures caused by a change to production, not outages such as a data center failure.
• 2024: deployment rework rate is added, giving five metrics in two groups.

How do you measure each DORA metric?

Measure each DORA metric for one application or service at a time, using records the delivery pipeline already keeps: commit and deployment timestamps for lead time and frequency, and deployment and incident records for recovery time, change fail rate and rework rate. DORA suggests starting with a team conversation or its Quick Check before building integrations.

• Change lead time: for each deployment, the time from commit to running in production. Report the median, because a few long-lived branches distort an average.
• Deployment frequency: production deployments per day, week or month from the CI/CD system, or the time between them.
• Failed deployment recovery time: from the moment a deployment needs immediate intervention to the moment service is restored. Leave out incidents that no change caused, such as a cloud provider outage.
• Change fail rate: deployments that needed immediate intervention, typically a rollback or a hotfix, divided by all deployments in the period.
• Deployment rework rate: unplanned deployments made because of a production incident, divided by all deployments. DORA's 2024 survey asked how many deployments in the last six months were not planned but were performed to address a user-facing bug.

The DORA Quick Check asks five multiple-choice questions, takes less than a minute and compares your answers with others in the industry; DORA says it does not store answers. It gives a baseline before anyone invests in automated collection.

What are the DORA performance levels?

The DORA performance levels are clusters, most recently elite, high, medium and low, that emerge from the survey answers rather than being set in advance. In the 2024 report, elite teams had a change lead time under one day, deployed on demand, had a 5% change fail rate and recovered from a failed deployment in under an hour.

Two details are easy to miss. The 2024 clusters were computed on the original four metrics, not rework rate, to stay comparable with earlier years. And the medium cluster had a lower change fail rate than the high cluster: DORA chose to call the faster teams high performers and the slower but more stable teams medium performers.

The 2025 report did not repeat the four-level table. It published the distribution of answers for each of the five metrics, plus seven team profiles, from foundational challenges and the legacy bottleneck to harmonious high-achievers, that combine delivery performance with product performance, friction and burnout.

DORA's advice on the levels has been consistent: improving matters more than reaching a level, and the most useful comparison is the same service over time. As the 2024 report puts it, the best teams are those that achieve elite improvement, not necessarily elite performance.

What did DORA find about AI and delivery performance?

DORA's 2025 research found that AI adoption now has a positive relationship with software delivery throughput but still a negative relationship with delivery stability. It drew on survey responses from nearly 5,000 technology professionals, 90% of whom use AI at work, and concluded that AI speeds development but can expose weaknesses further down the pipeline.

The report names the control systems that keep added change volume from turning into instability: strong automated testing, mature version control practices and fast feedback loops. For anyone tracking DORA metrics, the practical reading is to watch both groups in the same window. If throughput rises after a team adopts AI coding tools while change fail rate or rework rate rises too, the pipeline is shipping more change than its tests and reviews can absorb.

How are DORA metrics commonly misused?

DORA metrics are most often misused as targets, rankings or single numbers. DORA's own guide warns against treating them as goals, which invites gaming; relying on one metric; comparing unlike applications; and using them to compete with other teams or organizations. They describe a delivery system for one service, not the performance of a person.

• Turning them into targets. Set a deployment-frequency goal and teams split work into trivial deploys. DORA cites Goodhart's law for exactly this reason.
• Watching one metric. Deploying less often can lower change fail rate while batching risk into bigger releases. The metrics are useful because they pull against each other.
• Ranking teams. A payments service and an internal dashboard have different constraints, so comparing their numbers says nothing about which team is better.
• Measuring individuals. The metrics are defined per application or service. Attach them to one person's performance review and the numbers stop describing the system.
• Blaming the industry. DORA lists citing industry or regulation as a reason not to improve as a pitfall, and its 2024 report found that industry does not meaningfully affect performance levels.
• Building dashboards instead of improving. DORA warns against putting measurement tooling ahead of the improvement it is meant to guide.