DORA metrics are four measures of software delivery performance identified by the DevOps Research and Assessment programme. Their value is that they are in tension: improving any one at the expense of the others shows up immediately in the others.
The four
- Deployment frequency — how often you release to production. A throughput measure.
- Lead time for changes — commit to running in production. A speed measure.
- Change failure rate — what share of deploys cause a degradation needing remediation. A quality measure.
- Time to restore service — how long recovery takes when something breaks. A resilience measure.
Why they are measured together
Deploy less often and change failure rate improves — you have not got better, you have batched risk. Deploy constantly with no tests and frequency looks excellent while failure rate and restore time collapse. The set resists the usual single-metric gaming because the cheating shows up next door.
The moment they stop measuring anything
Put DORA metrics on a performance dashboard tied to individuals or teams and they become a target, at which point they stop being a measurement. Deployment frequency rises via trivial commits; lead time falls by redefining when the clock starts. Use them as a system-level signal about the delivery pipeline, never as a scoreboard.
The counterintuitive finding
The consistent result across DORA's research is that speed and stability move together rather than trading off. Teams that deploy frequently also recover faster and fail less — because small, frequent changes are easier to test, easier to reason about and easier to revert. The perceived trade-off between moving fast and being safe is largely an artefact of large batch sizes.
Measuring them without a project
- Deployment frequency — count production deploys from your CI system. Available today, no instrumentation needed.
- Lead time — commit timestamp to deploy timestamp. Requires linking commits to releases, which most pipelines already do.
- Change failure rate — deploys followed by a rollback, hotfix or incident, divided by total deploys. Needs a consistent definition of 'failure' more than it needs tooling.
- Time to restore — incident start to resolution, which your incident process should already record.
The hard part is agreeing definitions, not collecting data. Write them down, because a change in definition will otherwise be indistinguishable from a change in performance.
Where AI-assisted delivery complicates them
Faster authoring pushes deployment frequency and lead time up without necessarily improving delivery. Watch change failure rate and time to restore in the same window — if throughput rose while those degraded, the pipeline is now shipping more of something it understands less. That is precisely the pattern the four-metric set exists to expose.
Frequently Asked Questions
What counts as elite performance?
DORA publishes evolving benchmarks by cohort, but comparing against your own trend is more useful than against an industry band, since context varies enormously.
Do these apply to teams that deploy weekly by necessity?
Yes - regulated or embedded contexts still benefit from tracking the trend. The absolute numbers matter less than whether they are moving and why.
Is there a fifth metric?
Reliability was added in later research as a measure of operational performance. The original four remain the core set for delivery.
References
- DORA — DevOps Research and Assessment — DORA / Google Cloud
- The Agentic Engineering Trends Report 2026 — SaaSRise
About Jishu Labs
Jishu Labs is a software development company founded in 2016. We build custom software, AI/ML systems, and full-stack web and mobile applications for clients, and we make eight AI tools for software teams.