Recommended Free Tools
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
The traditional four DORA metrics are deployment frequency, lead time for changes, change fail rate, and recovery time. They remain useful shorthand, but they are not the complete current framework: DORA now defines five software delivery performance metrics, adding deployment rework rate and refining recovery time as failed deployment recovery time.
What are the four traditional DORA metrics?
The original four are a way to discuss how quickly a team delivers software and how often production changes cause trouble. DORA’s 2024 report describes them as measures of throughput and stability, and includes changes of any kind, such as code and configuration changes. DORA’s 2024 Accelerate State of DevOps Report uses the historical terms below.
- Deployment frequency: How often application changes reach production, or the time between deployments. It indicates delivery throughput.
- Lead time for changes: How long it takes a code change to move from commitment to version control to successful production deployment. DORA’s current guide calls this change lead time.
- Change fail rate: The share of deployments that require immediate intervention, such as a rollback or hotfix. It indicates instability.
- Recovery time: How long it takes to restore service after a change causes production impairment. Older descriptions may call this mean time to recover (MTTR) or time to restore service.
These are related signals, not four independent scores to maximize. Frequent deployments alone do not prove that delivery is healthy: speed should be read alongside failures, recovery, and unplanned corrective work.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Why does DORA now have five metrics?
DORA’s current software delivery performance framework has five measures. Its guide groups three under throughput and two under instability. DORA’s current metric guide defines them as follows:
#1 Best Overall
| Metric | What it measures | How leaders can use it |
|---|---|---|
| Change lead time | Elapsed time from a code change committed to version control until it is successfully deployed to production. | Use it to understand how quickly a change moves through the delivery path. |
| Deployment frequency | How often application changes are deployed over a period, or the time between deployments. | Use it as a throughput signal, interpreted with the service’s change and failure patterns. |
| Failed deployment recovery time | Time required to recover from a deployment that fails and requires immediate intervention. | Use it to assess how quickly the team restores service after a production-change failure. |
| Change fail rate | The proportion of deployments that require immediate intervention after deployment. | Use it to see how often deployments create instability requiring action. |
| Deployment rework rate | The proportion of deployments that were unplanned and made to address a user-facing production bug. | Use it to make corrective bug-fix deployments visible rather than relying only on failure proxies. |
DORA’s history explains the change. The 2014 study began with four variables: deployment frequency, lead time for changes, mean time to recover, and change fail rate. Recovery was later narrowed to focus on service impairment initiated by a production change, rather than unrelated events such as a data-center outage. In 2024, DORA added deployment rework rate because change fail rate was only a proxy for rework and did not directly capture all unplanned bug-fix deployments. See DORA’s history of software delivery metrics, dated January 2, 2026.
How should executives read throughput and instability together?
Throughput describes movement along the normal delivery path; instability captures the consequences and recovery work associated with production changes. DORA classifies change lead time, deployment frequency, and failed deployment recovery time as throughput measures, and change fail rate and deployment rework rate as instability measures. Its value-stream guidance distinguishes normal delivery work from incident recovery work.
- Look for balance: A faster cadence is not, by itself, evidence of better performance. Read throughput alongside failure frequency, recovery time, and bug-fix rework.
- Distinguish failed deployments from rework: Change fail rate tracks deployments that need immediate intervention; deployment rework rate also captures unplanned deployments addressing user-facing production bugs.
- Use trends to prompt investigation: A change in one measure can help identify where to examine the delivery or recovery path, but the metric alone does not explain the cause.
What should teams compare—and what should they keep consistent?
DORA says the metrics work for any kind of technology an organization delivers, but are best suited to one application or service at a time. The guide’s scope advice matters when leaders compare teams or periods: a portfolio-wide average can combine services with very different release patterns and operating conditions.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchBefore comparing results, align the measurement boundaries:
- Scope: Measure a single application or service, and keep that scope consistent across the periods or teams being compared.
- Definitions: Agree on what counts as a deployment, a successful production release, immediate intervention, a user-facing bug, and recovery.
- Observation window: Use the same time period and collection rules for each comparison.
- Remediation boundary: Decide consistently whether hotfixes, rollbacks, fix-forward changes, or patches count as intervention or rework. DORA’s Core Research Questions includes these as examples of remediation.
Where do DORA’s current Quick Check questions fit?
DORA’s current Quick Check asks about a primary application or service using four reader-facing questions: how often code reaches production, how long committed code takes to get there, how long recovery takes after a change degrades service, and what share of changes require remediation. The DORA Quick Check is therefore not a reason to describe the broader current framework as only four metrics; DORA’s metric guide separately defines five, including deployment rework rate.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
