DORA metrics are the five software delivery performance measures defined by DORA, Google Cloud’s DevOps Research and Assessment program: deployment frequency, change lead time, failed deployment recovery time, change fail rate and deployment rework rate. The first three measure throughput; the last two measure instability. Together they show how quickly and safely a team ships changes.
DORA surveys technology professionals every year about how they build and run software. The metrics are the part of that research most teams adopt: outcome measures for the delivery process of one application or service, whatever its stack. They do not tell you which practice to change; they tell you whether your changes are working.
Not to be confused with the EU’s Digital Operational Resilience Act (Regulation (EU) 2022/2554), also abbreviated DORA, which sets ICT resilience rules for financial entities. We cover that one in our multi-region and disaster recovery analysis.
Key takeaways
- Five metrics, two factors. Change lead time, deployment frequency and failed deployment recovery time measure throughput. Change fail rate and deployment rework rate measure instability.
- Recovery time counts as speed, not stability. DORA’s 2024 report groups it with throughput because it measures how fast any change moves, including a fix.
- The 2024 elite band was change lead time under one day, on-demand deploys, a 5% change fail rate and recovery in under an hour, and 19% of respondents were in it.
- Benchmarks are a snapshot, not a target. DORA’s own advice is to aim for elite improvement, not elite performance. Its 2025 research reframed performance as seven team profiles.
- Measure per service, from real events. Commits, deploys and incidents are enough. Never rank teams on the results.
What are the five DORA metrics?
DORA’s current guide to its software delivery performance metrics lists five measures in two factors. Throughput is how many changes can move through the system over a period of time. Instability is how well those deployments go. The second column follows DORA’s wording; the third is our translation into events you already have.
| Metric | What it measures | How to measure it | Factor |
|---|---|---|---|
| Change lead time | The time it takes for a change to go from committed to version control to deployed in production | For each production deploy, subtract each included commit’s timestamp from the time the deploy finished; report the median per service over a rolling window | Throughput |
| Deployment frequency | The number of deployments over a given period, or the time between deployments | Count successful deployments to production (or releases to end users) per service, per day or week, from the deploy tool’s events | Throughput |
| Failed deployment recovery time | The time it takes to recover from a deployment that fails and requires immediate intervention | From the failed deploy, or the incident it opened, to the moment service is restored by rollback, fix forward or hotfix; report the median | Throughput |
| Change fail rate | The ratio of deployments that require immediate intervention following a deployment, likely a rollback or a hotfix | Failed deploys divided by all deploys in the same window, where a deploy is failed when it is linked to an incident, a rollback or a hotfix | Instability |
| Deployment rework rate | The ratio of deployments that are unplanned but happen as a result of an incident in production | Unplanned deploys made to fix a user-facing bug divided by all deploys, using a label or change type on the deploy or its pull request | Instability |
DORA recommends measuring one application or service at a time, and its 2024 report counts configuration changes as well as code changes. Its research has repeatedly found that speed and stability are not a trade-off: top performers do well on all five metrics and low performers do poorly on all five.
Why is recovery time counted as throughput?
It looks like a stability measure, and for most of DORA’s history it was grouped as one. The 2024 Accelerate State of DevOps Report explains the regrouping. Change lead time, deployment frequency and failed deployment recovery time together measure “the speed of making updates of any kind, normal changes and changes in response to a failure.” Change fail rate and rework rate measure “the likelihood deployments unintentionally lead to immediate, additional work.” A fast recovery is a fast change that happens to be a fix.
The 2024 report called the second factor stability. DORA’s current guide and its 2025 survey questions call it instability, which makes the direction explicit: higher is worse. The 2025 survey still asks the same five questions under those two headings.
From four keys to five: how the metrics changed
If you learned DORA as “the four keys”, your model is a few versions old. DORA’s history of its software delivery metrics (January 2026) sets out the changes.
| Year | What changed |
|---|---|
| 2014 | The first study starts with four variables: deployment frequency, lead time for changes, mean time to recover (MTTR) and change fail rate. Change fail rate did not fit the statistical model that year, so IT performance was defined by the other three. |
| 2015 | The model settles into throughput (deployment frequency and lead time) and stability (MTTR and change fail rate). |
| 2018 | Availability is added as a measure of operational health, and the construct becomes software delivery and operational (SDO) performance. |
| 2021 | Availability broadens to reliability. DORA has since said that reliability is an operational measure, and that calling it a “fifth metric” that year was inaccurate. |
| 2023 | MTTR is renamed and redefined as failed deployment recovery time, which counts only failures caused by a change to production, not external events such as a data center outage. |
| 2024 | Deployment rework rate is added to test the idea that change fail rate is a proxy for rework. The result is five metrics in two factors: throughput and instability. |
DORA benchmarks: the 2024 performance levels
DORA benchmarks usually mean its performance-level table, and the latest edition we could verify at a primary source is in the 2024 Accelerate State of DevOps Report. DORA asked respondents about the primary application or service they work on and ran a cluster analysis on the answers. It deliberately used the original four metrics, leaving out rework rate, so the results stayed comparable with earlier years. DORA does not set the levels in advance; four clusters emerged from the responses. The table below is transcribed from page 13 of the report (v.2024.3).
| Performance level | Change lead time | Deployment frequency | Change fail rate | Failed deployment recovery time | Percentage of respondents* |
|---|---|---|---|---|---|
| Elite | Less than one day | On demand (multiple deploys per day) | 5% | Less than one hour | 19% (18-20%) |
| High | Between one day and one week | Between once per day and once per week | 20% | Less than one day | 22% (21-23%) |
| Medium | Between one week and one month | Between once per week and once per month | 10% | Less than one day | 35% (33-36%) |
| Low | Between one month and six months | Between once per month and once every six months | 40% | Between one week and one month | 25% (23-26%) |
On page 15, the same report sets elite performers against low performers: 127x faster lead time, 182x more deployments per year, 8x lower change failure rate and 2293x faster failed deployment recovery times. Those ratios describe the gap between two survey clusters. They are not a forecast of what any one team will gain.
How to read the bands
- High and medium are not a strict ladder. The medium cluster has a lower change fail rate (10%) than the high cluster (20%). DORA called the faster teams high and the slower but more stable teams medium, and says which is better depends on the application, the team’s goals and, above all, what users expect.
- The levels are re-derived every year. They are a snapshot of that year’s respondents, not a fixed standard, so the same numbers can land in a different band from one report to the next.
- Industry is not an excuse. DORA reports that industry rarely predicts software delivery performance, and it sees high-performing teams in every industry vertical.
- Improvement beats the label. In the report’s words, “The best teams are those that achieve elite improvement, not necessarily elite performance.”
What changed in DORA’s 2025 research
The 2025 report, State of AI-assisted Software Development, changed the framing. DORA wrote that “simple software delivery metrics alone aren’t sufficient. They tell you what is happening but not why it’s happening.” The 2025 announcement describes a cluster analysis that produced seven team profiles, or archetypes, each combining performance, stability and well-being; examples include “Foundational challenges” and “Harmonious high achievers”. The five metrics are still in the survey; what changed is the lens, which now pairs them with team health to choose the right intervention.
The same research shows why you need both factors. In 2025 DORA found a positive relationship between AI adoption and delivery throughput, but a continuing negative one with delivery stability. Track only deployment frequency and AI-assisted teams can look faster while shipping more rework. The AI figures from both reports are on our DevOps and cloud statistics page.
How to measure DORA metrics from your pipeline
Start with one service. DORA warns against “focusing on measurement at the expense of improvement”: integrating every system for precise numbers may not be worth it at first, while a team conversation or the Quick Check below gives you a baseline in minutes. Automate once you know what you are improving.
Define the events before you write a query
Most disputes about DORA numbers are really disputes about definitions. Agree these four per service, write them down and keep them stable:
- A deployment is a change reaching production or being released to end users. DORA’s survey asks how often you deploy “code to production or release it to end users”, so a mobile app counts store releases. Configuration changes count too, and we treat infrastructure changes the same way. Deploys to staging do not.
- A failure is a deployment that degrades service (an impairment or an outage) and needs remediation: a hotfix, a rollback, a fix forward or a patch. That wording is DORA’s. A build that fails in CI, or a rollout halted before users see it, is not a change failure: nothing reached production. Your SLOs are the best test of “degraded”.
- Recovery is the time from the failed deployment until service is restored, not until the root cause is fixed. Since 2023 it covers only failures caused by a change; a cloud provider outage belongs in your reliability data instead.
- Rework is a deployment that was not planned and was made to fix a user-facing bug. DORA’s survey asks what share of deployments in the last six months fit that description.
Where the data lives
| Source | Events to capture | Feeds |
|---|---|---|
| Version control | Commit timestamps, merge events, pull request labels such as bug or hotfix | Change lead time, deployment rework rate |
| CI/CD or deploy tool | Deploy start and finish, target environment, status, artifact version and the commit range each deploy contains | Deployment frequency, change lead time, and the denominator for both rates |
| Incident management | Incident opened and resolved, severity, and the ID of the deploy that caused it | Change fail rate, failed deployment recovery time |
| Issue tracker | Work type (planned feature versus bug fix) for the change behind each deploy | Deployment rework rate |
DORA’s open-source Four Keys project shows the shape of a working setup. It classifies toolchain events into changes, deployments and incidents and computes the metrics as views over them. The repository is no longer maintained, but its maintainers encourage using it as inspiration, and the model is sound. The alternative, DORA’s guide notes, is a source-available or commercial product with pre-built integrations.
Rules that keep the numbers honest
- Stamp every production deploy with a deploy ID, the service name and the commit range it shipped. Without the commit range there is no lead time.
- Link incidents to deploys at triage, while the responder still knows which release went out. Reconstructing the link weeks later in a postmortem is how change fail rate quietly drifts down.
- Watch your merge strategy. The Four Keys README warns that squash merging breaks the link between the trunk commit and the branch commits it replaced, so time from the original commit can no longer be measured.
- Report medians and trends per service, weekly or monthly, rather than a single organization-wide average that blends a mainframe batch system with a web front end.
Start with DORA’s Quick Check
Before you build anything, take the DORA Quick Check. It asks five multiple-choice questions about your team’s software delivery performance, takes under a minute, compares your answers with the rest of the industry and suggests which capabilities to work on first. DORA says it does not store your answers or personal information. Take it as a team: when the answers differ, you have found the conversation worth having. DORA suggests repeating it, alongside retrospectives, to check progress.
DORA metrics anti-patterns
The old warning that “when a measure becomes a target, it ceases to be a good measure” is the reason most DORA programs go wrong. DORA puts it plainly: broad mandates like “Every application must deploy multiple times per day by year’s end” increase the likelihood that teams will try to game the metrics. The common failure modes:
- Turning the metrics into targets. Once deployment frequency appears in a performance review, it stops describing your delivery process.
- Gaming deploy counts. Splitting one release into trivial deploys, redeploying an unchanged artifact or counting non-production deploys raises frequency without shipping anything faster. Reading it alongside lead time and the two rates exposes the trick.
- Relabelling failures. Calling a rollback “planned”, closing the incident before service is restored or keeping hotfixes out of rework flatters both rates. If change fail rate improves while users keep complaining, check the labels.
- Comparing and ranking teams. DORA lists “making disparate comparisons” and “competing” as pitfalls: a mobile app and a mainframe system have different constraints, and the goal is each team improving over time.
- One metric to rule them all. DORA advises several metrics with a healthy tension between them, which is exactly what throughput and instability give you.
- Siloed ownership. If development owns frequency and operations owns fail rate, you have built a tug of war. DORA recommends sharing all five across development, operations and release teams.
- Using the industry as a shield. Some teams in regulated industries argue that compliance rules out changing how they deliver. DORA lists this as a pitfall, and its data finds high-performing teams in every industry vertical.
How DORA metrics relate to SRE and platform engineering
DORA and SRE error budgets
DORA metrics describe the delivery system: how changes reach production and how often they hurt. Site reliability engineering describes the user’s experience of the running service through SLOs and the error budget they imply. DORA’s own history draws the same line: it describes reliability as a measure of operational performance rather than software delivery performance. They share data: a change-caused incident burns error budget and also counts toward change fail rate and recovery time.
They also interact by design. Google’s example error budget policy halts all changes and releases other than P0 issues or security fixes while a service is over its error budget for the preceding four-week window. Deployment frequency then drops on purpose. That is the policy working, not a delivery regression, and one more reason never to read a DORA number without its context. The DevOps vs SRE vs platform engineering comparison sets out which discipline owns which KPI.
DORA and platform engineering
A platform team’s customers are other engineers, so the DORA metrics of the services built on its platform are among its best outcome measures. DORA’s data is a caution. In 2024, respondents using an internal developer platform saw productivity and organizational performance gains, but DORA called out an “unexpected downside”: throughput was about 8% lower than for teams without a platform, and change stability decreased. Where respondents were required to use the platform exclusively for the whole app lifecycle, throughput was 6% lower. DORA’s suggested counter is to stay user-centered and build toward developer independence. By 2025, the DORA report found that 90% of organizations had adopted at least one platform. If yours is one, check that it moves these five numbers the right way.
How to improve DORA metrics
The common lever DORA’s guide recommends is reducing the batch size of changes. Smaller changes move through the pipeline faster and are easier to recover from, so the same habit helps throughput and instability together. DevOps practices such as continuous integration, continuous delivery and trunk-based development sit in DORA’s capability catalog alongside working in small batches. DORA’s routine for a cross-functional team:
- Set a baseline for one application with the Quick Check.
- Talk through the friction points in the delivery process; mapping the process helps.
- Commit as a team to improving the most significant constraint.
- Turn that into a plan with leading indicators, such as how long code reviews take or the quality of your tests.
- Do the work, check progress with the Quick Check and retrospectives, and repeat.
In our DevOps engagements, DORA metrics start reporting from the pipeline itself as the baseline, so every later milestone is measured rather than asserted. To see where your practice stands across more than delivery, the free DevOps maturity assessment scores six dimensions and points you at the two weakest first.
Want a second opinion on your numbers, or on whether they measure what you think? InfraZen runs a free 30-minute review that ends in honest advice on the one constraint worth removing first. Book the review.
Related: What is DevOps? · What is SRE? · What is platform engineering? · DevOps vs SRE vs platform engineering · What is observability? · DevOps and cloud statistics · DevOps services