DORA metrics explained: five measures, two examples, better decisions.
DORA's current software-delivery guide describes five measures—three for throughput and two for instability. None is an executive decision by itself. Here's how to read them together, calculate illustrative failure rates, and identify useful next actions.
What do DORA metrics measure?
DORA metrics describe the speed and stability of software delivery for an application or service. They help teams understand whether changes move through delivery efficiently and whether production deployments create avoidable disruption.
Change lead time, deployment frequency, failed deployment recovery time.
Change fail rate, deployment rework rate.
Source: DORA's official software delivery performance metrics guide , updated January 5, 2026.
The five current DORA metrics
Keep definitions, numerators, denominators, sample windows and service boundaries consistent over time. The original four-key model evolved; this guide follows DORA's current five-metric description.
Change lead time
Elapsed time from a committed change in version control until that change is deployed to production.
Decision context: Review time distributions and bottlenecks at the application or service level, rather than chasing a universal target.
Deployment frequency
How often software is deployed to production during an explicit observation window.
Decision context: Frequency measures delivery cadence, not whether the changes were safe, valuable, or low-risk.
Failed deployment recovery time
Time required to restore service after a failed deployment that needed immediate intervention.
Decision context: Document consistent incident boundaries, recovery approach, and what delayed restoration.
Change fail rate
The proportion of deployments that need immediate intervention after deployment, such as a rollback or hotfix.
Decision context: Interpret the rate with service criticality, change types, incident severity, and a meaningful sample size.
Deployment rework rate
The proportion of deployments that are unplanned responses to production incidents.
Decision context: Keep remediation deployments distinct from initial deployments that caused a failure.
Calculate change fail rate
A fictional service made 10 production deployments during one agreed reporting period. Two needed immediate intervention: one rollback and one hotfix.
Example numbers only. A 20% rate from ten deployments is not a real customer measurement, a league-table ranking, or sufficient evidence to diagnose the root cause.
What should a leader ask next?
Identify the application, deployment type, and observation window.
Distinguish a minor internal issue from an externally disruptive incident.
Examine rollback, hotfix, detection, response, and recovery pathways.
Assign an owner, select a scoped action and choose a follow-up review date.
Deployment rework rate is a different question
Suppose a separate fictional application recorded 20 deployments during a reporting period. Three were unplanned deployments to remediate production incidents. Its illustrative deployment rework rate is:
3 unplanned incident-response deployments ÷ 20 total deployments = 15%
This does not mean that 15% of its changes failed. These metrics classify different events. A deployment may fail and require a hotfix; an additional deployment made to remediate that incident belongs in the unplanned rework category when the measurement definition applies.
Do not combine the 20% change fail rate from the first example with this 15% rework rate: the examples describe different fictional services and periods.
A useful dashboard includes context and a decision record
A strong measurement practice connects a defined signal to responsible analysis, a selected action, and a later evidence review.
- Set a boundary: name the application, window, definition, data source and owner.
- Interpret together: compare cadence and lead time with failures, remediation and recovery.
- Add governance context: include security, reliability, customer impact and risk signals where relevant, but do not rename them as DORA metrics.
- Record a decision: specify action, owner, scope, expected observation and review date.
- Reassess: review the same service over time with comparable definitions and relevant context.
DORA cautions against treating metrics as targets to be gamed or comparing unrelated services without context. The purpose is improvement, not a leaderboard.
Questions practitioners actually ask
What are the five current DORA software delivery metrics?
Change lead time, deployment frequency, failed deployment recovery time, change fail rate, and deployment rework rate. The first three describe throughput, while the last two describe instability.
How do you calculate change fail rate?
For a defined service and observation window, divide deployments that required immediate intervention by total deployments, then multiply by 100. In the hypothetical example of 2 interventions out of 10 deployments, the rate is 20%.
Is deployment rework rate the same as change fail rate?
No. Change fail rate classifies deployments that required immediate intervention; deployment rework rate describes unplanned deployments made in response to production incidents. Report them separately.
Are security vulnerabilities one of the five DORA metrics?
No. Vulnerability findings, remediation age, and control exceptions may be valuable DevSecOps governance signals, but they should not be mislabeled as one of DORA's five software delivery performance metrics.
Where does the DevSecOps Metrics Playbook fit?
Stephen W. King's published Playbook covers measurement and governance decisions beyond a single metric. King Holdings Publications maintains the confirmed paperback destination and a separate, publisher-linked Gumroad bundle offer.
Build the governance around the metrics
DevSecOps Metrics Playbook: From Signals to Decisions, by Stephen W. King, expands from signals to interpretation and practical governance. The Kindle and paperback editions have been published; the paperback listing is confirmed by a KDP notice.
The publisher also supplies a separate Gumroad Playbook + Professional Implementation Toolkit bundle link. Its current price, included files and checkout terms have not been independently confirmed.