The five DORA metrics at a glance
| Metric | Factor | What it measures | Desired direction |
|---|---|---|---|
| 1. Change Lead Time | Throughput | Time from a code commit to that change running successfully in production. | Lower is generally better |
| 2. Deployment Frequency | Throughput | The number of deployments over a given period, or the time between deployments. | Higher is generally better |
| 3. Failed Deployment Recovery Time | Throughput | Time to recover from a deployment that fails and requires immediate intervention. | Lower is generally better |
| 4. Change Fail Rate | Instability | The percentage of production changes that require immediate remediation such as a rollback, hotfix, fix-forward, or patch. | Lower is generally better |
| 5. Deployment Rework Rate | Instability | The percentage of deployments that were unplanned and performed in response to a production incident or user-facing bug. | Lower is generally better |
Throughput and instability
Throughput combines Change Lead Time, Deployment Frequency, and Failed Deployment Recovery Time. Instability combines Change Fail Rate and Deployment Rework Rate. Read the factors together: faster delivery is not an improvement if it creates more failed or unplanned remediation deployments.
Definitions and formulas
1. Change Lead Time
Time from a code commit to that change running successfully in production.
How to calculate it: Elapsed time from commit to successful production deployment.
Factor: Throughput. Direction: Lower is generally better.
2. Deployment Frequency
The number of deployments over a given period, or the time between deployments.
How to calculate it: Successful production deployments per period, or elapsed time between deployments.
Factor: Throughput. Direction: Higher is generally better.
3. Failed Deployment Recovery Time
Time to recover from a deployment that fails and requires immediate intervention.
Terminology: Failed Deployment Recovery Time is formerly Time to Restore Service; often shortened to MTTR. For DORA, it measures recovery from a failed production change; it is narrower than a general incident MTTR across every cause.
How to calculate it: Elapsed time from a failed deployment to restored service.
Factor: Throughput. Direction: Lower is generally better.
4. Change Fail Rate
The percentage of production changes that require immediate remediation such as a rollback, hotfix, fix-forward, or patch.
How to calculate it: Deployments requiring immediate intervention ÷ total deployments × 100.
Factor: Instability. Direction: Lower is generally better.
5. Deployment Rework Rate
The percentage of deployments that were unplanned and performed in response to a production incident or user-facing bug.
How to calculate it: Unplanned remediation deployments ÷ total deployments × 100, measured over a consistent window such as the last six months.
Factor: Instability. Direction: Lower is generally better.
What changed from the original Four Keys?
DORA introduced Deployment Rework Rate in its 2024 research, and its current model now contains five software delivery metrics. Failed Deployment Recovery Time is the narrower current name for the recovery measure previously described as MTTR or Time to Restore Service. The DORA Quick Check was updated in April 2026 to report five individual scores plus overall, throughput, and stability scores. See the DORA software delivery performance metrics, DORA metrics history, and DORA Quick Check updates.
What the research means in practice
The metrics are most useful as a balanced system. Improving one score by shifting work or risk into another is not an improvement. DORA also cautions against turning the metrics into universal goals or comparing unlike applications.
Track the same service, definitions, and measurement window over time. Use the weakest factor to locate the constraint, then validate whether a delivery or reliability change improved the whole system.