What is DORA Metrics?

Change lead time measures how long it takes a change to move from commit to production. Deployment frequency measures how often an application or service is deployed. Failed-deployment recovery time measures how long it takes to recover from a deployment that fails and requires immediate intervention.

Change fail rate is the proportion of deployments that require immediate intervention, such as a rollback or hotfix. Deployment rework rate is the proportion of deployments that are unplanned and occur in response to a production incident. DORA currently groups change lead time, deployment frequency, and failed-deployment recovery time under throughput, and change fail rate and deployment rework rate under instability.

A recurring finding in the research is that speed and stability tend to move together rather than trading off. Teams that deploy frequently often recover faster and fail less often, because small frequent changes are easier to verify, diagnose, and reverse.

• Balanced view: throughput and instability are measured together, so neither can be optimized in isolation without the other showing it.
• Actionable: each metric points at a specific part of the delivery pipeline.
• Comparable: the five metrics give teams a common vocabulary for discussing software-delivery performance.
• Evidence-based: the metrics come from research across many organizations rather than from intuition.

A common misuse is treating the metrics as targets for individual teams to hit. Deployment frequency in particular can be gamed by splitting one change across five deploys, which improves the number and nothing else. The metrics should be interpreted together and in the context of a specific application or service.

They also describe the delivery process rather than the outcome. A team can deploy hourly with strong recovery times and build software nobody wants. DORA measures how well you ship, not whether what you ship is worth shipping.

SRE metrics such as SLIs, SLOs, and error budgets describe the service as users experience it: is it fast enough, correct enough, available enough.

DORA metrics describe the engineering system that produces the service: how quickly changes flow and how often they destabilize production. They answer different questions and are complementary. A team can have strong DORA metrics and miss its SLOs, which can mean it ships fast and the architecture cannot support the reliability target. The reverse, strong SLOs with weak DORA metrics, can mean reliability is being bought with slow, painful releases.