DORA metrics
Also known as: four key metrics, DORA four keys
DORA metrics are four measures of software delivery performance identified by the DevOps Research and Assessment (DORA) program: deployment frequency, lead time for changes, change failure rate, and time to recover from failures.
They balance speed against stability. While they're widely used to compare teams, their creators warn against exactly that: the metrics are for a team to improve itself, not for managers to rank people.
DORA metrics, explained at three levels
At home
Think of a fitness tracker that measures a few key numbers, like steps, heart rate, sleep, and recovery, to give an overall picture of your health. DORA metrics do this for a software team. They track how often the team releases updates, how quickly a change goes live, how often releases break something, and how fast the team recovers when they do.
At work
DORA metrics are four measures of software delivery performance, identified by the DevOps Research and Assessment program after years of surveys. Two measure speed: deployment frequency and lead time for changes. Two measure stability: change failure rate and recovery time after a failed deployment. Businesses care because the research shows strong performers are both faster and more stable, so the metrics reveal where delivery is stuck.
At home
Each metric measures a different part of the journey from a developer's finished change to a working update. Deployment frequency counts how often new code reaches users. Lead time for changes measures how long a finished change waits before going live. Change failure rate is the share of releases that cause problems. Recovery time measures how fast service returns to normal after a bad release. Together they show both speed and stability.
At work
At work, DORA metrics are calculated automatically by joining data from three sources: version control for commit times, CI/CD for deployment events, and incident tools for failures and recovery. Lead time runs from commit to production; change failure rate links incidents back to the deployments that caused them. The annual DORA report groups respondents into performance clusters for benchmarking, but trends within your own team matter more than comparisons with others.
At home
The four metrics work as a set because they pull against each other. Shipping faster without care raises the failure rate; being extra careful slows lead time. Yet any single number can be gamed, an effect known as Goodhart's law: splitting one release into ten tiny ones inflates deployment frequency without helping anyone. In my opinion, DORA metrics work best when the team chooses to track them, not when they're imposed.
At work
DORA's research rests on survey data analyzed with cluster analysis and statistical modelling, linking the four metrics to organizational outcomes. Recent reports renamed time to restore service as failed deployment recovery time, added rework rate as a fifth measure, and studied AI coding tools. Definitions must be consistent before trends mean anything: what counts as a deployment, a failure, and a recovery. Use the metrics to find bottlenecks, such as approval boards or flaky tests, not to rank people.
Real-world examples
At home
Nadia volunteers on an open-source project and was curious how healthy it was. She calculated its DORA metrics from GitHub data and found that while releases were frequent, fixes for broken releases took over a week, which became the community's next focus.
At work
Jerome is a VP of engineering at an Ottawa software company. His teams' lead time was 18 days. DORA data showed most of it was waiting for a weekly change approval board. Replacing it with automated checks cut lead time to two days without more incidents.
Common confusions
- DORA metrics are related to the EU's DORA regulation. — No. DORA metrics come from the DevOps Research and Assessment program. The EU's Digital Operational Resilience Act is an unrelated financial-sector law.
- Faster delivery means more outages. — DORA research found the highest performers are both faster and more stable.
- DORA metrics should be used to rank teams. — Their creators advise using them for a team's own improvement, since ranking invites gaming.
For analysts
DORA metrics are a good way to turn 'IT is slow' into something measurable. I'd collect a baseline before any process change, so you can show whether the change actually helped instead of arguing from anecdotes.
History & origin
DORA began with the annual State of DevOps reports, starting around 2014, and was founded as a company by Nicole Forsgren, Jez Humble, and Gene Kim. Their 2018 book Accelerate presented years of survey research showing that the four metrics predicted both delivery and organizational performance, and that speed and stability rose together rather than trading off. Google acquired DORA in late 2018 and continues the annual research. In 2023, 'time to restore service' was reframed as failed deployment recovery time, and recent reports have explored a fifth measure, rework rate, along with the effects of AI coding tools. In my view, the finding that fast teams are also the stable ones is still the most useful thing to tell a cautious executive.