Definition
DORA Metrics
DORA metrics are four research-backed measures of software delivery performance: deployment frequency, lead time for changes, change failure rate, and time to restore service. Identified by the DevOps Research and Assessment program, they balance speed (the first two) against stability (the last two), giving engineering teams an evidence-based scorecard for how well they ship.
Key takeaways
- DORA metrics are four measures of delivery performance: deployment frequency, lead time for changes, change failure rate, and time to restore service.
- They balance speed (the first two) against stability (the last two) — all four must be read together.
- DORA's key finding is that speed and stability correlate, not trade off: elite teams ship more often AND recover faster AND fail less.
- They're a system mirror for finding bottlenecks, not individual targets — turned into personal goals they get gamed and lose meaning.
The four metrics pair off into two dimensions. Speed is captured by deployment frequency (how often you release to production) and lead time for changes (how long a commit takes to reach production). Stability is captured by change failure rate (what fraction of deployments cause a problem) and time to restore service (how quickly you recover when one does). Looking at all four together is the point — optimizing speed while ignoring stability, or vice versa, produces a brittle or sluggish team.
DORA's central finding, from years of large-scale research, is that speed and stability are not a trade-off but correlated: the highest-performing teams ship more frequently and recover faster and fail less. Small, frequent, automatically-tested changes are both quicker to deliver and safer than large infrequent ones, so the practices that improve one dimension tend to improve the other.
The metrics are a mirror, not a target. Used to find and remove bottlenecks — a slow pipeline, a fragile deploy process, a missing rollback — they drive real improvement. Turned into individual performance goals, they invite gaming and lose meaning, the same failure mode that corrupts velocity. They describe a system's delivery health, which is a team-level property.
Planoda's signed webhooks and audit trail let a team connect deploy and incident events back to the issues they touched, so DORA-style delivery and recovery measures can be grounded in the same record as the work itself.
Related terms
- CI/CD (Continuous Integration / Continuous Delivery)CI/CD is the practice of automatically building, testing, and releasing code through a pipeline triggered by every change. Continuous integration merges and verifies work frequently to catch conflicts early; continuous delivery keeps the software always in a releasable state, often deploying automatically. Together they shorten the path from a commit to running in production.
- Lead TimeLead time is the total elapsed time from when an issue is first created or requested to when it is delivered. Unlike cycle time, it includes the waiting period in the backlog before work begins. Lead time reflects the customer's experience of how long a request actually takes end to end.
- ThroughputThroughput is the number of work items a team completes in a given period — issues finished per week, for example. It is the simplest flow metric: a direct count of output over time. Tracked across periods, throughput reveals a team's real delivery capacity and is the basis for probabilistic, estimate-free forecasting.
- Cycle TimeCycle time is how long an issue takes from the moment work actively starts on it to the moment it is done. Measured in hours or days, it captures the team's hands-on flow efficiency. Shorter, more consistent cycle times mean a more predictable system — the core flow metric Kanban teams optimize.