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
DORA metrics are like a fitness tracker for a software team. Instead of steps and heart rate, they track how often the team ships updates, how quickly changes go live, how often updates break things, and how fast problems get fixed.
At work
DORA metrics give leaders a simple, research-based way to see whether software delivery is improving. Two metrics measure speed and two measure stability, so teams can't look good by sacrificing one for the other.
At home
The four metrics are: deployment frequency (how often code reaches production), lead time for changes (from commit to production), change failure rate (share of deployments causing problems), and recovery time (how fast service is restored after a failure).
At work
Most teams collect DORA metrics automatically from version control, CI/CD pipelines, and incident tools. Annual DORA reports group performers into clusters, giving benchmarks, but trends within your own team over time matter more than comparisons with others.
At home
Any metric that becomes a target gets gamed, an idea known as Goodhart's law. Splitting one deployment into ten tiny ones boosts 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
Use DORA metrics as conversation starters about bottlenecks, such as slow reviews, flaky tests, or manual approvals, rather than as performance scores. Pair them with developer experience surveys and business outcomes. Definitions need care: what counts as a 'failure' or a 'deployment' must be consistent before trends mean anything.
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.