DORA Metrics definition
DORA metrics are measures of software delivery performance identified by the DevOps Research and Assessment (DORA) program. The original four keys are deployment frequency, lead time for changes, change failure rate and time to restore service, now called failed deployment recovery time, and since 2024 DORA also tracks deployment rework rate. Together they show how quickly a team delivers changes and how reliably those changes run in production.
The DORA metrics
DORA's research, summarized in the 2018 book Accelerate by Nicole Forsgren, Jez Humble and Gene Kim, found that speed and stability are not trade-offs: high-performing teams are better at both. DORA, now part of Google Cloud, publishes regular DevOps research, which now also studies AI-assisted software development, and later reports have refined the names and definitions, so check current guidance when setting up measurement.
- Deployment frequency: how often code is successfully deployed to production.
- Lead time for changes: time from a commit to that code running in production.
- Change failure rate: share of deployments that cause a failure needing a fix or rollback.
- Failed deployment recovery time, formerly time to restore service: how long it takes to recover from a failed deployment.
- Deployment rework rate: share of deployments that are unplanned fixes for production incidents.
How to measure DORA metrics
The data already exists in your tools. Version control provides commit times, the CI/CD system records deployments, and the incident management or monitoring tool records failures and recovery. The hard part is agreeing definitions: what counts as a deployment, which incidents count as change failures, and when recovery is complete. Write them down so numbers stay comparable over time.
GitLab includes DORA metrics reporting, and engineering analytics tools such as LinearB, Sleuth and Swarmia calculate them from GitHub, Jira and incident data. A simple script over deployment and incident logs is often enough to start. Accuracy improves as definitions settle and data sources are connected.
How to improve each metric
- Deployment frequency: automate deployments, shrink batch sizes and remove manual release steps.
- Lead time: speed up CI, keep pull requests small and reduce waiting for reviews and approvals.
- Change failure rate: strengthen automated tests, use canary releases and feature flags, and review risky changes carefully.
- Recovery time: invest in observability, one-click rollback, runbooks and practiced incident response.
- All of them: make work visible, so bottlenecks are found from data rather than opinion.
Common pitfalls
When a measure becomes a target, people optimize the number rather than the outcome. Splitting one change into many trivial deployments inflates frequency without helping anyone. DORA metrics describe team and system capability; they should never be used to rank individual developers or to compare teams with very different products and constraints.
They also do not capture everything. Pair them with measures of developer experience, such as surveys or frameworks like SPACE, and with business outcomes, so faster delivery is shown to deliver value rather than just more releases. Customer satisfaction and reliability targets complete the picture.
Example: using DORA metrics to guide change
A team measures a lead time of two weeks and finds most of it is pull requests waiting for review and a slow, flaky test suite. It sets a review service level, fixes flaky tests and parallelizes CI, and lead time drops to a couple of days within a quarter, while change failure rate holds steady. Nexzem baselines DORA metrics at the start of DevOps engagements and reports them monthly, so clients see the impact of each improvement.