What are DORA metrics? The five measures, explained
DORA metrics are five measures of software delivery: change lead time, deployment frequency, recovery time, change fail rate and deployment rework rate.
DORA metrics are five measures of software delivery performance: change lead time, deployment frequency and failed deployment recovery time (throughput), plus change fail rate and deployment rework rate (instability). They describe how fast and how safely one application or service gets changes into production. The widely quoted “four keys” became five in 2024.
They don’t measure developer productivity, rank teams or explain why a number moved. Used well, they give a team a shared, low-argument starting point for a conversation about delivery.
Who DORA is
DORA stands for DevOps Research and Assessment. Its first study ran in 2014, in partnership with Puppet as an extension of Puppet’s State of DevOps research. DORA’s annual reports and the book Accelerate (Nicole Forsgren, Jez Humble and Gene Kim, IT Revolution, 2018) grew out of that work. Google acquired DORA in December 2018, and it now runs as a Google Cloud program. The metrics predate that, so “Google’s metrics” is the wrong label: they are a research program’s measures.
A detail often missed: DORA’s own research gathers these numbers by survey, asking respondents about “the primary application or service they work on” (2024 report, p. 13). Pipeline data is one route to the numbers, not the only valid one.
The five DORA metrics
DORA’s metrics guide splits the five into two factors. Throughput is “how many changes can move through the system over a period of time.” Instability is “how well the software deployments go.”
| Metric | Factor | DORA’s definition |
|---|---|---|
| Change lead time | Throughput | Time for a change to go from committed to version control to deployed in production |
| Deployment frequency | Throughput | Number of deployments over a given period, or the time between deployments |
| Failed deployment recovery time | Throughput | Time to recover from a deployment that fails and requires immediate intervention |
| Change fail rate | Instability | Ratio of deployments that require immediate intervention, likely a rollback or hotfix |
| Deployment rework rate | Instability | Ratio of deployments that are unplanned but happen as a result of an incident in production |
Change lead time
The clock starts at commit and stops at production. That makes it a measure of your delivery pipeline and review process, not of how long a ticket sat in the backlog. DORA’s 2025 report still calls it lead time for changes; the guide’s current name is change lead time.
- Measure it: for each change that reaches production, subtract the commit timestamp from the deploy timestamp. Report the median per week or month, because one long-lived branch will drag a mean upward for no useful reason.
- Watch for: starting the clock at ticket creation. That’s a different, longer lead time, which the lead time vs cycle time chapter covers. Don’t mix the two in one trend.
Deployment frequency
How often you deploy to production, or the time between deployments.
- Measure it: count production deployments per service from your deployment tool’s log.
- Watch for: counting deploys to staging, or adding up deploys across twenty services and reporting the total as one team’s frequency.
Failed deployment recovery time
This is the metric most people still search for as mean time to recovery (MTTR) or time to restore service. Same idea, narrower scope. In 2023 DORA renamed and redefined it because the older definitions “did not distinguish between a failure initiated by a software change and a failure caused by external factors, such as a data center outage.” Today it counts only recovery from a deployment that failed.
- Measure it: for each failed deployment, time from the failure being detected to service being restored, whether by rollback, fix forward or patch. Use the median.
- Watch for: including incidents with no deployment behind them (a cloud provider outage, an expired certificate). Track those as reliability instead.
Change fail rate
The share of deployments that need immediate intervention. Most pages, and parts of DORA’s own 2024 report, call it change failure rate; the guide says change fail rate.
- Measure it: failed deployments divided by total deployments over the period. Agree in writing what “failed” means (rolled back, fixed with a hotfix, or degraded service needing remediation) before you count.
- Watch for: fix-forward changes no one labels as failures. The rate improves and nothing else does.
Deployment rework rate
The share of deployments that were unplanned and happened because of an incident in production. This is the newest of the five. 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 in the application.”
- Measure it: tag each deployment as planned or unplanned when it happens, and divide unplanned by total.
- Watch for: confusing it with change fail rate. Change fail rate counts the deploy that broke something. Rework rate counts the extra deploys you shipped to deal with production problems.
Four or five DORA metrics?
Five, as of DORA’s 2024 report and its current guide. The “four keys” were deployment frequency, lead time for changes, change failure rate and time to restore service; by 2015 DORA had grouped them as throughput and stability. Two changes since then explain why sources disagree:
- 2023: time to restore service (MTTR) became failed deployment recovery time, with the narrower scope above.
- 2024: DORA had a “longstanding hypothesis that the change failure rate metric works as a proxy for the amount of rework a team is asked to do” (2024 report, p. 11). It added a rework question to test it, found the two metrics formed “a reliable factor of software delivery stability,” and the fifth metric, deployment rework rate, joined the set.
Some pages list reliability as the fifth. That comes from the 2021 report, which DORA’s history of the metrics now says “inaccurately called the ‘reliability’ metric the ‘fifth metric’,” since reliability measures operations, not delivery.
Performance levels: read them by year
DORA doesn’t set performance levels in advance. They emerge each year from a cluster analysis of survey answers, so thresholds and even the number of groups change. Three clusters appeared before 2018, four from 2018 to 2021, three in 2022, and four again in 2023 and 2024 (per DORA’s FAQ).
The 2024 report (p. 13) clustered on the original four metrics, to stay comparable with earlier years:
| 2024 level | Change lead time | Deployment frequency | Change fail rate | Recovery time | Share of respondents |
|---|---|---|---|---|---|
| Elite | Less than one day | On demand (multiple deploys per day) | 5% | Less than one hour | 19% |
| High | One day to one week | Once per day to once per week | 20% | Less than one day | 22% |
| Medium | One week to one month | Once per week to once per month | 10% | Less than one day | 35% |
| Low | One to six months | Once per month to once every six months | 40% | One week to one month | 25% |
Look at the medium row: a lower change fail rate than high, but slower.
The 2025 report took a different cut, combining throughput and instability with measures such as burnout and time spent on valuable work, and found seven team profiles. Delivery numbers alone can miss how the work feels to the people doing it, the side of a team that team dynamics covers.
What DORA metrics can’t tell you
The 2025 report says the five metrics “tell you what is happening, but they don’t explain why.” Its example is a low deployment frequency that could come from technical debt, bureaucratic processes or team burnout, with the metrics alone unable to say which.
In practice: your change lead time doubles over a quarter. The data can show where the time goes, perhaps changes waiting in review. It takes the team to say why: the test suite got flaky, so people batch changes to avoid rerunning it, and only one person feels safe approving the payments service. That conversation is what a retrospective or a health check is for. The from metrics to action chapter covers how to run that loop.
Velocity is not one of the five. Story points measure a team’s own pace at its own calibration, which is why velocity works inside the team and breaks outside it. DORA’s metrics don’t measure people’s experience of the work either; that’s the gap the SPACE framework and developer experience metrics aim at.
Using DORA metrics without breaking them
DORA’s guide lists the pitfalls, and they are worth taking literally:
- Don’t set them as targets. A mandate like “Every application must deploy multiple times per day by year’s end” invites gaming, Goodhart’s law in action.
- Don’t rely on one metric. DORA advises several, “including some with a healthy amount of tension between them.” Speed without the instability pair looks great right up to the incident.
- Measure one application or service at a time. DORA calls blending metrics across teams or whole organizations “problematic,” and comparing a mobile app with a mainframe system misleading.
- Share ownership, and compete with your own past. Give development, operations and release the same five numbers, and compare a service with itself, not with other teams.
- Don’t let measurement crowd out improvement. DORA suggests starting with conversations, its five-question Quick Check, or an existing tool before building custom integrations.
Teams without pipeline data can also start from TeamRetro’s DORA Metrics Self-Assessment for Teams, which gives a baseline to revisit.
Improving the numbers
DORA’s recommended loop: gather the cross-functional team that builds and runs the service, set a baseline, and talk about where delivery hurts. Commit to the single biggest constraint, with a leading indicator such as how long code reviews take. Do the work, check progress with “the DORA Quick Check, conversations, and team retrospectives,” and repeat.
The lever DORA’s guide singles out is smaller batches: smaller changes move through delivery faster and are easier to recover from, so they help throughput and instability at once. That fits the finding that speed and stability are not a trade-off: “top performers do well across all five metrics, and low performers do poorly.” On the backlog side, smaller batches start with slicing stories vertically.
For where these five fit among the other frameworks, see the agile metrics guide.
Frequently asked questions
What are the 4 key DORA metrics?
The original four keys were deployment frequency, lead time for changes, change failure rate and time to restore service (MTTR). DORA now uses five: change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate, added in the 2024 report.
Is MTTR a DORA metric?
Not under that name. Mean time to recovery (time to restore service) was one of the original four keys. In 2023 DORA renamed it failed deployment recovery time and limited it to failures caused by a change to production. It is the same idea with a narrower scope.
What is the difference between change fail rate and deployment rework rate?
Change fail rate is the share of deployments that need immediate intervention, such as a rollback or hotfix. Deployment rework rate is the share of deployments that were unplanned and made because of an incident in production. The first counts the deploys that broke something; the second counts the extra deploys made to deal with production problems.
Should DORA metrics be used to compare teams?
No. DORA says the metrics are best applied to one application or service at a time, and lists comparing very different applications and competing with other teams as pitfalls. Compare a service with its own past, not with a different team’s service.
How do you improve DORA metrics?
Fix the biggest constraint, not the worst-looking number. DORA’s guide suggests the cross-functional team sets a baseline, discusses friction in delivery, commits to the most significant bottleneck, then checks progress and repeats. Reducing batch size is a common lever.
Related reading
- Agile and engineering metrics: the hub, with DORA beside the other frameworks.
- The SPACE framework: five dimensions of developer productivity, and how DORA fits inside them.
- Lead time vs cycle time: the flow-metric definitions that DORA’s lead time is often confused with.
- From numbers to actions: turning a DORA trend into a retro action.
- Is velocity a useful metric?: why story points stay inside the team.