DORA has five software delivery metrics now, and its own guidance says not to rank teams with them

Free AI Tool · CIOPages

Get Your Personalized Career Growth Plan

Answer four short sections about your role, competencies, and aspirations. Our AI generates a comprehensive, actionable plan — with certification recommendations, networking strategy, and a 3-year roadmap — tailored specifically to technology executives.

~8 minutes CIOPages AI Advisor Download as Word Refresh for current market

Build My Career Plan

DORA now uses five software delivery metrics, not four. DORA's metrics guide lists change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate. "Time to restore service" no longer exists under that name: DORA renamed and redefined it in 2023 as failed deployment recovery time. Use the five on one application or service at a time, to see whether that service is improving against its own history. DORA's own guidance warns against turning them into targets or ranking teams with them.

The five metrics, as dora.dev defines them

DORA splits the five into two groups. Throughput is "how many changes can move through the system over a period of time." Instability is "how well the software deployments go." The definitions below are quoted from the metrics guide, last updated January 5, 2026.

Metric	Group	dora.dev definition
Change lead time	Throughput	The amount of time it takes for a change to go from committed to version control to deployed in production
Deployment frequency	Throughput	The number of deployments over a given period or the time between deployments
Failed deployment recovery time	Throughput	The time it takes to recover from a deployment that fails and requires immediate intervention
Change fail rate	Instability	The ratio of deployments that require immediate intervention following a deployment
Deployment rework rate	Instability	The ratio of deployments that are unplanned but happen as a result of an incident in production

Recovery time now sits under throughput. In 2015 DORA grouped it with change fail rate as a stability measure, according to its history of the metrics. The 2024 DORA report (page 12) explains the grouping: the throughput factor "measures the speed of making updates of any kind, normal changes and changes in response to a failure."

What changed since the four keys

The metrics have been revised several times. According to DORA's history of the metrics, dated January 2, 2026:

The 2014 study began with deployment frequency, lead time for changes, mean time to recover and change fail rate.
In 2023, mean time to recover was renamed failed deployment recovery time. The old definition did not separate a failure caused by a software change from one caused by something external, such as a data center outage. The new one counts only recovery after a change to production caused an impairment.
In 2024, DORA added deployment rework rate as a fifth metric, to test its hypothesis that change fail rate was a proxy for rework.
The 2021 report called reliability the "fifth metric." The history page now says that label was inaccurate, because reliability measures operational performance, not software delivery performance.

If your dashboards still show MTTR measured from every incident, they are measuring something DORA stopped measuring in 2023.

Where the data comes from

The five metrics draw on three kinds of record.

Version control supplies commit timestamps, the start of change lead time.
The deployment pipeline supplies deployment events: the end of lead time, the count behind deployment frequency, and the denominator for both rates.
Incident and issue tracking supplies which deployments failed, when service recovered, and which deployments were unplanned fixes.

The records then have to be joined. Each failed deployment has to be linked to the change that caused it, and each fix deployment has to be marked as unplanned. The DORA team's open-source project Four Keys, shows the shape of the work. It collects events from GitHub or GitLab, sorts them into "changes", "deploys" and "incidents", and lets you reclassify them, for example to use an incident label other than "incident". Its README warns that squash merging "breaks the link between the commit into trunk and the commits from the branch," which stops lead time from being measured on those commits. The repository is marked as not currently maintained.

DORA's resources page lists source-available tools that collect and visualize the metrics. Examples include Apache DevLake, Liatrio's backstage-dora-plugin, Middleware and OpenDORA. The metrics guide also mentions commercial products with pre-built integrations. Check which definition each tool implements before you compare its numbers with anything else.

Write down your definition of rework before you count it. The metrics guide ties rework to "an incident in production." The 2024 survey question (page 11) asked how many deployments "were not planned but were performed to address a user-facing bug." Those are not always the same deployments.

The metrics guide says integrations to many systems "might not be worth the initial investment," and suggests starting with conversations, the DORA Quick Check, or a product with pre-built integrations.

Throughput and instability usually move together

DORA's position is that speed and stability are not a trade-off. The metrics guide says "the metrics are correlated for most teams. Top performers do well across all five metrics, and low performers do poorly."

The split into two groups exists because the correlation is not perfect. The 2024 report (page 11) says: "More than half of the teams in our study this year show differences in software throughput and software stability." Read the two groups side by side. A rising deployment frequency with a rising change fail rate means the team is moving faster and breaking more.

How DORA reports performance levels

DORA's levels come from survey answers. The 2024 report (page 3) says DORA "collects data through an annual, worldwide survey." On page 13, DORA describes running a cluster analysis on the original four metrics, letting the levels emerge from the responses rather than setting them in advance. Four clusters emerged:

Level	Change lead time	Deployment frequency	Change fail rate	Failed deployment recovery time	Share of respondents
Elite	Less than one day	On demand (multiple deploys per day)	5%	Less than one hour	19%
High	Between one day and one week	Between once per day and once per week	20%	Less than one day	22%
Medium	Between one week and one month	Between once per week and once per month	10%	Less than one day	35%
Low	Between one month and six months	Between once per month and once every six months	40%	Between one week and one month	25%

Source: 2024 DORA report, page 13. The shares carry an 89% uncertainty interval.

The medium cluster has a lower change fail rate than the high cluster. The same report (page 14) says DORA "made a decision to call the faster teams 'high performers,' and the slower but more stable teams 'medium performers.'" It adds that improving "should be more important to a team than reaching a particular performance level."

These levels describe self-reported survey answers in bands. Your pipeline produces exact timestamps. Placing a team in a band is a rough comparison, not a measurement against a standard.

For the 2025 report, Google Cloud's announcement, dated September 23, 2025, says a cluster analysis produced "seven common team profiles or archetypes," each combining performance, stability and well-being. The Quick Check FAQ says the Quick Check compares your results with benchmarks from DORA's 2025 research.

How DORA says not to use them

The metrics guide lists these pitfalls:

Setting metrics as a goal. Its example is "Every application must deploy multiple times per day by year's end," which it says "increases the likelihood that teams will try to game the metrics."
One metric to rule them all. Teams should use several metrics, "including some with a healthy amount of tension between them."
Disparate comparisons. Comparing "a mobile app and a mainframe system" can mislead. The guide also says blending metrics across teams or entire organizations "can be problematic."
Competing. "The goal is to improve your team's performance over time, not to compete against other teams or organizations."
Siloed ownership. Giving development, operations and release teams separate metrics "can lead to friction and finger-pointing."

The 2024 report (page 74) goes further. The metrics should be used "at the application and service levels, and not at the organization or line-of-business level." They should be used to visualize continuous improvement "and not to compare teams," and "certainly not to compare individuals." They "should also not be used as a maturity model."

A league table of teams by deployment frequency breaks several of those rules at once. A bonus tied to change fail rate invites teams to stop classifying failures as failures.

What the five numbers leave out

Whether the software works for its users. The 2024 report (page 74) says "user feedback metrics are as important as the four key metrics."
Operational reliability. DORA's history page classes reliability as operational performance, separate from delivery.
Why the numbers moved. Google Cloud's 2025 announcement says: "Simple software delivery metrics alone aren't sufficient. They tell you what is happening but not why it's happening."
The people. The metrics guide says DORA's research shows the metrics predict organizational performance and team well-being. None of the five measures burnout or satisfaction. Those need surveys or conversations.
Individuals. The metrics describe a delivery system for one service. They say nothing about any one engineer.

Measure one service against its own last quarter

Pick one application. Agree with the team that builds and runs it how each metric is defined, especially what counts as a failed deployment and what counts as rework. Take a baseline from the Quick Check or the pipeline. Review the trend in the team's own retrospectives, and keep it out of performance reviews. Add a service only when the first one's numbers are trusted by the people who produce them.

Frequently asked questions

Are there four or five DORA metrics? Five. DORA added deployment rework rate in 2024, alongside change lead time, deployment frequency, failed deployment recovery time and change fail rate.

What replaced MTTR in DORA? Failed deployment recovery time, introduced in 2023. It counts only recovery from a failure caused by a change to production.

Sources: DORA, "DORA's software delivery performance metrics", last updated January 5, 2026. DORA, "A history of DORA's software delivery metrics", January 2, 2026. DORA, Accelerate State of DevOps Report 2024, v.2024.3, pages 3, 11 to 14 and 74; the 2024 errata correct only the table colors on page 13. Google Cloud, "Announcing the 2025 DORA Report", September 23, 2025. DORA, FAQ and resources. Four Keys README on GitHub. DORA revises its metric names, definitions and groupings: re-check the metrics guide whenever a new annual DORA report is published, and replace the performance-level table if a later report publishes its own levels. The table is from the 2024 report; the 2025 report's seven team profiles are described here only as Google Cloud's announcement describes them.