How-to
How to Measure and Improve DORA Metrics in 7 Steps
- Throughput
- Instability
- Loglune
On this page
DORA metrics are the five software delivery performance measures in DORA’s research: change lead time, deployment frequency, and failed deployment recovery time measure throughput, and change fail rate and deployment rework rate measure instability. This guide measures and improves DORA metrics in 7 steps: pick one application or service, set a baseline with the DORA Quick Check, define what counts as a deployment and a failure, collect the timestamps for each metric, record flag changes next to deployments, choose the biggest constraint with the team, and check progress before repeating the cycle.
The steps apply to a team that builds, deploys, and operates one application or service from version control. Ranking teams or companies against each other is outside the scope, because DORA’s guide lists competing and comparisons between very different applications among the pitfalls of the metrics.
What DORA metrics mean
DORA’s guide DORA’s software delivery performance metrics (last updated January 5, 2026) names five metrics and splits them into two factors. Throughput measures how many changes pass through the delivery system in a period, and instability measures how well the deployments go. The guide says DORA’s research shows that the metrics predict better organizational performance and well-being for team members, that speed and stability are not tradeoffs, and that the metrics are correlated for most teams.
| Metric | Factor | Definition in the DORA guide | Data to record |
|---|---|---|---|
| Change lead time | Throughput | Time for a change to go from a commit in version control to a deployment in production | Commit time and production deploy time of each change |
| Deployment frequency | Throughput | Number of deployments in a period, or the time between deployments | Time of each production deployment |
| Failed deployment recovery time | Throughput | Time to recover from a deployment that fails and needs immediate intervention | Time of the failed deployment and time service recovered |
| Change fail rate | Instability | Ratio of deployments that need immediate intervention afterward, likely a rollback or a hotfix | Whether each deployment needed a rollback, hotfix, or other immediate intervention |
| Deployment rework rate | Instability | Ratio of deployments that are unplanned and happen because of an incident in production | Planned or unplanned tag and the linked incident for each deployment |
DORA’s post A history of DORA’s software delivery metrics (January 2, 2026) explains how the set grew from four metrics to five. The 2014 study began with four variables, deployment frequency, lead time for changes, mean time to recover (MTTR), and change fail rate, and defined IT performance with the first three, because change fail rate did not significantly correlate with the other three in that year’s analysis. By 2015, the model grouped deployment frequency and deployment lead time as throughput measures and MTTR and change fail rate as stability measures. In 2023, DORA renamed and redefined MTTR as failed deployment recovery time, because the earlier definitions did not separate a failure initiated by a software change from a failure with an external cause such as a data center outage, and DORA’s history post points to the appendix of the Accelerate State of DevOps 2023 report for the reasoning. In 2024, DORA researchers identified change failure rate as a proxy for the amount of rework a team does, and added deployment rework rate to test that finding.
Before you measure DORA metrics
Four inputs decide whether the numbers mean the same thing from one period to the next.
- Version control that keeps the commit time of every change to the application.
- A deploy log with the time of every production deployment and a tag for planned or unplanned work.
- An incident record that links each failure to the deployment or change that caused it.
- Agreement that development, operations, and release teams share all five metrics, because DORA’s guide lists siloed ownership as a pitfall that leads to friction and finger-pointing.
How to measure and improve DORA metrics in 7 steps
1. Pick one application or service to measure
Measure one application or service at a time. DORA’s guide says the metrics work for any type of technology but suit one application or service at a time, and that blending metrics across teams or whole organizations can be problematic because each application has its own context. Pick an application the team builds, deploys, and operates, and keep the numbers of other applications in separate reports.
2. Set a baseline with the DORA Quick Check
Start with the DORA Quick Check, which the DORA guide names as the first of its next steps for setting a baseline. On September 16, 2026, the Quick Check asked five questions about the application or service a respondent works on, one per metric. Lead time and failure recovery are answered with ranges from less than one hour to more than six months, deploy frequency with ranges from on demand to less than once per six months, and change fail rate and deployment rework rate as percentages.
Take the baseline before building data integrations. The DORA guide warns that building integrations to several systems for precise data might not be worth the initial investment, and suggests starting with conversations, the Quick Check, or a source-available or commercial product that comes with pre-built integrations.
3. Define what counts as a deployment, a failure, and rework
Write three counting rules before collecting any numbers, because change fail rate, failed deployment recovery time, and deployment rework rate all count or time deployments.
- A deployment: every release of the application to production, and whether a flag change that exposes new code to users counts as a change.
- A failed deployment: a deployment that needed immediate intervention, such as a rollback, a hotfix, a fix forward, or a patch.
- Rework: an unplanned deployment made because of an incident in production.
The DORA guide’s definitions name deployments and do not mention feature flags. The Quick Check’s failure questions cover a change to production or a release to users that degrades service and needs remediation. A team that releases code with flags therefore chooses one rule, either counting flag changes that release code to users as changes or reporting flag-caused failures next to the deployment-based numbers, and keeps that rule fixed across periods.
4. Collect the timestamps for each metric
Calculate each metric from the records in the table, using the same period for all five.
| Metric | Calculation |
|---|---|
| Change lead time | Production deploy time minus commit time, for each change; report one fixed statistic such as the median |
| Deployment frequency | Production deployments in the period, or the time between deployments |
| Failed deployment recovery time | Time from the failed deployment to recovered service, for each failed deployment |
| Change fail rate | Deployments that needed immediate intervention ÷ all deployments in the period |
| Deployment rework rate | Unplanned deployments made because of a production incident ÷ all deployments in the period |
A deployment that ships several commits contains several changes, and each change has its own commit time, so change lead time is calculated per change, not per deployment.
5. Record flag changes next to deployments
When a failure starts after both a deployment and a flag change, the team has to decide which change caused it before counting it in change fail rate or failed deployment recovery time. A deploy log records builds, but a flag rule can change without a deploy, so the flag state at the failure time needs its own record.
In Loglune, every flag edit is appended to the change history as a change event with the customer, the actor, the time, the target flag, and the values before and after. Pick the affected customer and the time the failure started, and Loglune rebuilds the flag state at that time from the change history and delivers it in reproduction mode to a development, CI, or staging environment. One delivery counts as one reproduction, and Loglune reproduces the flag evaluation, not the root cause in application code. Setting the rebuilt flag state next to the deploy log shows the build and the flag values the affected customer had when the failure started, and the rule from step 3 decides which metric the failure counts toward. The walkthrough on reproducing a bug that affects one customer shows the path from a customer report to a reproduction.
6. Choose the biggest constraint with the cross-functional team
Gather the people who prioritize, build, deliver, and operate the application, and pick one constraint to improve. The DORA guide’s next steps have that team talk through the friction points in the delivery process, with a map of the process if it helps, commit as a whole team to improving the most significant constraint or bottleneck, and turn the commitment into a plan with leading indicators such as how long code reviews take or the quality of tests. The same guide names reducing the batch size of changes as a common approach, because smaller changes move through the delivery process more easily and are easier to recover from after a failure.
7. Check progress and repeat
Check progress with the Quick Check, team conversations, and retrospectives, then repeat the cycle from step 6, as the last two of the DORA guide’s next steps describe. Compare the application with its own earlier periods under the same counting rules, and keep the numbers out of targets and team rankings. The guide warns that setting metrics as goals, such as a rule that every application must deploy several times a day by the end of the year, makes teams more likely to game the metrics.
Editorial example (not a customer case): one quarter of DORA metrics under two counting rules
The table shows one service over a 13-week quarter with 52 production deployments and 30 flag changes that released code to users. The numbers are illustrative.
| Metric | Rule A: deployments | Rule B: deployments and flag releases |
|---|---|---|
| Changes counted | 52 | 52 + 30 = 82 |
| Deployment frequency | 52 ÷ 13 weeks = 4 per week | 4 per week, because flag changes are not deployments |
| Changes that needed immediate intervention | 4 deployments | 4 deployments + 2 flag changes = 6 |
| Change fail rate | 4 ÷ 52 = 7.7% | 6 ÷ 82 = 7.3% |
| Recovery time, median | 35 minutes (20, 25, 45, 90) | 22.5 minutes (5, 8, 20, 25, 45, 90) |
| Deployment rework rate | 3 ÷ 52 = 5.8% | 3 ÷ 52 = 5.8% |
The same quarter gives two change fail rates and two recovery times, so each reported number carries its counting rule. Deployment rework rate is the same under both rules because DORA defines it over deployments. In the example, the two flag-caused failures surfaced when the team rebuilt the affected customers’ flag state at the failure time, and switching the flags back restored service in 5 and 8 minutes without a deploy.
Troubleshooting DORA metrics
- The numbers improve while customers report more problems: check whether the metrics became targets, because the DORA guide warns that setting metrics as goals makes teams more likely to game them.
- Two teams argue over whose numbers are better: stop the comparison, because the guide lists competing with other teams and comparing very different applications, such as a mobile app and a mainframe system, as pitfalls.
- One metric takes over the discussion: report all five together, because the guide advises tracking several metrics, including metrics that pull against each other.
- Integration work delays the first numbers: take the Quick Check and hold the team conversation first, because the guide says integrations to several systems might not be worth the initial investment.
- Change fail rate jumps after a process change: check whether the counting rule from step 3 changed, and compare periods under the same rule.
- Failures after flag changes appear in no metric: decide in step 3 whether flag changes that release code to users count, and record each flag change with its time and actor.
FAQ
What is DORA in DevOps?
DORA is the research program behind the DORA metrics. The DORA site (checked September 16, 2026) describes DORA as a research program that seeks to understand the capabilities that drive software delivery and operations performance. DORA’s history post says DORA has investigated the capabilities that drive high-performing technology organizations for over a decade, and that software delivery performance metrics have been the center of that research throughout that history.
Are there four or five DORA metrics?
There are five DORA metrics since 2024: change lead time, deployment frequency, failed deployment recovery time, change fail rate, and deployment rework rate. The DORA guide calls the earlier set the original four keys, and DORA’s history post lists them as deployment frequency, lead time for changes, mean time to recover, and change fail rate.
Do feature flag changes count in DORA metrics?
The DORA guide defines the metrics in terms of deployments and does not mention feature flags, while the Quick Check’s failure questions cover changes to production and releases to users. A team that releases code with flags writes down whether a flag change that releases code to users counts as a change, and reports that rule with the numbers, because the two rules can give different change fail rates for the same period, as the editorial example shows.
What are good DORA metrics for a team?
No fixed number fits every application. The DORA guide says context matters, that the metrics apply to one application or service at a time, and that the goal is to improve a team’s performance over time, not to compete with other teams or organizations. The guide also says top performers do well across all five metrics, so a team reads the five together and compares them with its own earlier periods.
Deciding what to report
Report all five DORA metrics for one application or service, with the counting rules for deployments, failures, rework, and flag changes written next to the numbers. Compare the application with its own earlier periods, and pick one constraint per cycle with the team that builds and operates it. Record every flag change with its time and actor, so a failure after a flag change is counted under the same rule as a failure after a deployment.
Count failures after flag changes the same way as failures after deployments
A failure that follows a flag change is hard to count when nobody recorded the change. Loglune records every flag edit as a change event with the actor, the time, and the values before and after, and rebuilds the flag state a customer had at time T for your development, CI, or staging environment. The Free plan includes 5 reproductions.