DORA Metrics
DORA metrics measure the performance of the technical delivery pipeline — how fast a team can move a change from code commit to production, and how well the system handles failure when it occurs. They are the standard empirical indicators of technical delivery capability in lean-agile organizations.
The four metrics were developed through the DevOps Research and Assessment program (DORA) and validated across thousands of teams and organizations. They characterize two related properties of a delivery system: throughput (how fast and frequently it delivers) and stability (how reliably it recovers when things go wrong).
Relationship to Flow Metrics
DORA metrics are not a replacement for flow metrics — they complement them.
Flow metrics (DVS Flow Metrics, Team Flow Metrics) describe how work items move through the delivery system — feature flow, story cycle times, WIP, and predictability. They measure the delivery management system.
DORA metrics describe how code changes move through the technical pipeline — from commit to production, and from failure to recovery. They measure the technical delivery capability underlying the flow system.
A DVS with healthy flow metrics and poor DORA metrics has a management system that is working well sitting on top of a fragile technical pipeline. Both sets of metrics are necessary for a complete picture.
The Four Metrics
1. Deployment Frequency
How often code is deployed to production.
This is the primary throughput metric for the technical pipeline. Frequency reflects how well the team has decomposed work, how mature the pipeline automation is, and how much trust the organization has in its deployment process.
Deployment frequency is not an end in itself — it is an indicator of delivery capability. Teams that deploy frequently have broken work into small, safe increments and automated the verification and deployment path.
| Performance level | Deployment frequency |
|---|---|
| Elite | Multiple times per day |
| High | Once per day to once per week |
| Medium | Once per week to once per month |
| Low | Less than once per month |
Measurement: Count of successful production deployments per time period (day, week, month).
2. Lead Time for Changes
The time from a code commit being merged to that change running in production.
This metric captures how long it takes the delivery pipeline to process a change — from the moment it is committed to when it is available in production. It reflects the speed and automation maturity of the CI/CD pipeline.
Lead Time for Changes is a pipeline health indicator, not a feature delivery metric. A short lead time does not mean features are delivered faster — it means that once development is complete, the pipeline moves quickly. Long lead times here often indicate manual steps, slow test suites, approval gates, or environment provisioning delays.
| Performance level | Lead time for changes |
|---|---|
| Elite | Less than one hour |
| High | One day to one week |
| Medium | One week to one month |
| Low | More than one month |
Measurement: Median time from commit merge to production deployment.
3. Change Failure Rate
The percentage of deployments that result in a degraded service or require remediation — rollback, hotfix, or patch.
Change Failure Rate measures the stability and quality of the pipeline. A high failure rate indicates problems with automated testing coverage, insufficient pre-production validation, or deployments that are too large to reason about safely.
Change Failure Rate is not the same as incident count — it specifically measures how often the act of deploying causes a production problem.
| Performance level | Change failure rate |
|---|---|
| Elite | 0–5% |
| High | 5–10% |
| Medium | 10–15% |
| Low | 15–30%+ |
Measurement: (Deployments causing production degradation / Total deployments) × 100
4. Mean Time to Restore (MTTR)
The average time to recover service after a production incident or degradation.
MTTR measures how quickly the system and the team can respond to and recover from failure. It reflects observability maturity (can you detect failures quickly?), on-call response capability, and the deployability of fixes (can you deploy a fix quickly when you have one?).
A low MTTR does not mean incidents are rare — it means that when they occur, the impact is contained and recovery is fast. This is the design goal of stable delivery systems: not zero failures, but fast recovery.
| Performance level | MTTR |
|---|---|
| Elite | Less than one hour |
| High | Less than one day |
| Medium | One day to one week |
| Low | More than one week |
Measurement: Mean elapsed time from incident detection to full service restoration.
Using DORA Metrics
As indicators, not targets
DORA metrics function best as diagnostic indicators. They reveal the current state of technical delivery capability and surface areas for improvement. Treating them as performance targets — setting goals directly on the numbers — tends to optimize the measurement rather than the underlying system.
A useful framing: use DORA metrics to understand where investment in technical capability is most needed, not to hold teams accountable for specific values.
Ownership
Deployment Frequency and Lead Time for Changes are primarily owned at team and DVS level — they reflect the team’s pipeline and deployment practices. Change Failure Rate and MTTR involve both development and operations — they require collaboration across whoever builds the software and whoever operates it.
In organizations with a Platform team or an SRE function, MTTR and Change Failure Rate are typically tracked jointly between the product teams and the platform/operations function.
Connection to improvement work
DORA metrics connect directly to the Enabler Feature investment decisions the DVS makes. A high Change Failure Rate points toward investment in automated testing and pre-production validation. A long Lead Time for Changes points toward pipeline automation and environment provisioning. MTTR improvement requires investment in observability tooling and incident response capability.
These are not abstract improvement goals — they translate into concrete Enabler Features in the DVS backlog.
Recommended Review Cadence
Per sprint (team) — Deployment frequency as a basic pipeline health check. Any change failure incidents reviewed in the sprint retrospective.
End of PI (DVS Inspect and Adapt) — Full review of all four metrics. Connect patterns to the improvement backlog. Identify Enabler Feature candidates.
Quarterly with leadership — Trend review across PIs. Connect DORA capability level to the DVS’s ability to deliver reliably at velocity.
Sources
- DORA (DevOps Research and Assessment) — Accelerate (Forsgren, Humble, Kim, 2018); the original research establishing these metrics as predictors of organizational performance
- DevOps Thinking — The intellectual foundation; see DevOps Thinking
- Continuous Delivery — The delivery pipeline practices that drive DORA metric improvement; see Continuous Delivery