DORA metrics
Also known as DORA software delivery metrics, Four keys
Definition
DORA metrics are a set of software delivery performance measures used to understand how quickly and reliably an application changes in production. The current model covers change lead time, deployment frequency, failed deployment recovery time, change fail rate, and deployment rework rate.
The current set of metrics
DORA's current guidance describes five measures:
Scroll horizontally if needed →
| Metric | What it describes |
|---|---|
| Change lead time | Elapsed time from a committed change to its deployment in production. |
| Deployment frequency | How often production deployments occur. |
| Failed deployment recovery time | Time needed to recover after a deployment fails and requires intervention. |
| Change fail rate | The share of deployments that require immediate corrective action. |
| Deployment rework rate | The share of deployments made unexpectedly in response to production incidents. |
Older articles often describe four keys. The terminology and model have evolved, so check the version behind a dashboard or benchmark before comparing numbers. A recovery measure restricted to failed deployments is not identical to an average calculated across every type of incident.
Define the application boundary
Take an illustrative company with a customer-facing API, a mobile app, and a reporting pipeline. Each has a different path to production. Combining their deployment counts into one organization-wide frequency can conceal more than it reveals.
An API may deploy several independent services throughout a day. A mobile release might wait on an external review process. The reporting pipeline may run on a schedule with its own definition of a production change. Start by agreeing on what application or service the measurement describes.
Then document which events count. If a pipeline retries a deployment three times before succeeding, is that one deployment or three? If a release is rolled back before users see a problem, how is it classified? Consistent answers matter more than a dashboard that looks precise but changes its rules between months.
Investigate the workflow behind a result
Imagine a service whose change lead time rises after the team introduces a new approval step. The metric identifies a delivery change, but it does not tell you whether the step is unnecessary. The additional review might be catching a serious class of defects.
Inspect the waiting time and the review findings together. Perhaps approvals wait overnight because only one person can provide them. Training another reviewer could shorten the queue without removing the protection.
This is where delivery metrics and development-stage measurements complement each other. The delivery result points to a question. Pull request history, release records, and the team's experience help answer it.
What these metrics do not establish
A deployment is not a unit of customer value. A team can release frequently while building the wrong thing. Similarly, a stable release does not prove that the code is easy to maintain or that the process is sustainable for its developers.
Read delivery measures alongside product outcomes, code quality, and developer experience. Use them to examine changes within a reasonably consistent context. Turning every measure into a target can reward changes to counting practices instead of changes to how software is delivered.
For AI-assisted development, the same distinction applies. Generating code faster helps only if the rest of the workflow can turn that code into useful, dependable releases.
How this relates to Weave
Weave's Engineering Intelligence brings delivery benchmarks together with pull request, quality, and review data. This helps teams connect a delivery trend to the development work behind it. Check the definitions and available integrations for each metric before assuming a dashboard implements every measure in the latest DORA model.
Explore Engineering intelligence