How do you know whether your engineering team is getting faster and more reliable, or just busier? The DORA metrics are the most widely used answer. They come from the DevOps Research and Assessment programme, now part of Google Cloud, whose annual State of DevOps research has studied thousands of teams over more than a decade.
What are the four DORA metrics?
- Deployment frequency: how often you successfully release to production.
- Lead time for changes: how long it takes a committed change to reach production.
- Change failure rate: the share of deployments that cause a failure in production needing a fix, rollback or hotfix.
- Failed deployment recovery time: how long it takes to restore service after a failed deployment. Earlier reports called this time to restore service.
Why measure speed and stability together
The first two metrics measure throughput and the last two measure stability. DORA’s research consistently found that the best-performing teams score well on both: speed and stability reinforce each other rather than trading off. Small, frequent changes are easier to test, review and roll back than large, rare ones. Tracking only speed encourages cutting corners; tracking only stability encourages never shipping.
How to measure them without a big project
- Deployment frequency and lead time come from your version control and CI/CD system: commit timestamps and deployment events.
- Change failure rate needs deployments linked to incidents or rollbacks. A simple label on incident tickets is enough to start.
- Recovery time comes from incident start and resolution times.
- Measure per service or team and look at trends over weeks, not single values.
How not to use DORA metrics
- Do not compare teams working on different systems; a payments service and a marketing site have different risk profiles.
- Do not turn them into individual targets. People will improve the number rather than the outcome, for example by splitting deployments.
- Do not treat them as the whole picture. They say nothing about whether you are building the right things; pair them with product and customer outcomes.
What usually moves the numbers
Teams that improve tend to do the same few things: smaller batches of work, trunk-based development or short-lived branches, automated testing in the pipeline, automated deployments with easy rollback, and good monitoring so failures are spotted in minutes. The metrics are not the goal; they tell you whether those practices are taking hold.
