Skip to main content

DORA Software Delivery Performance Metrics

What This Concept Is​

DORA's software-delivery metrics have evolved. The current model has five metrics grouped into throughput and instability:

  • Deployment Frequency. How often you ship to production.
  • Lead Time for Changes. From code commit to running in production.
  • Failed Deployment Recovery Time (formerly MTTR -- Mean Time To Restore). How long from a service-impacting failure to recovery.
  • Change Failure Rate. Percentage of deployments that cause a degraded service or require immediate intervention.
  • Deployment Rework Rate. Percentage of deployments that are unplanned work to repair a production problem.

Deployment frequency, lead time, and failed-deployment recovery time measure throughput. Change-failure and deployment-rework rates measure instability. DORA's research finds that speed and stability are not inherent tradeoffs; strong delivery systems tend to perform well across the set.

Historically, practitioners learned these as the “four keys.” Reliability was discussed as an operational-performance concern, but DORA's current five-metric delivery model added deployment rework rate and does not treat reliability as that fifth delivery metric. Use SLOs alongside delivery metrics to measure service reliability.

Why It Matters Here​

These metrics are a widely used empirical lens on delivery health. They let you:

  • compare two teams' delivery systems honestly, not by vibes
  • diagnose where your pipeline is weak (long lead time? high change-fail? slow recovery?)
  • justify investment in CI/CD to non-technical stakeholders
  • resist process growth that improves one metric while silently harming another

Small batches, continuous integration, loosely coupled teams, deployment automation, and fast feedback are capabilities associated with stronger delivery performance. Do not hard-code an old “Elite” threshold table into policy: DORA's definitions, metrics, clusters, and benchmarks have evolved. Compare against the current Quick Check when benchmarking, and prioritize improvement over ranking.

Concrete Example​

A hypothetical service report:

MetricBaseline value
Deployment Frequency3 deploys/week
Lead Time for Changes2 days
Failed Deployment Recovery Time4 hours
Change Failure Rate25%
Deployment Rework Rate15%

Reading this honestly: the team is deploying often enough, but 1 in 4 deploys hurts users and recovery is slow. The intervention is not "deploy less often" (that would make lead time worse). The intervention is probably: add a canary, automate rollback, and require a post-deploy smoke test. That targets change-fail rate and recovery without touching throughput.

Same team, six months later:

MetricBeforeAfter
Deployment Frequency3/week5/day
Lead Time2 days3 hours
Failed Deployment Recovery Time4 hours12 min
Change Failure Rate25%4%
Deployment Rework Rate15%3%

The throughput gains came because stability improved: a canary + automated rollback made smaller deploys safe, which made more frequent deploys socially acceptable.

Common Confusion / Misconception​

"Lead Time = time to merge." No. DORA's lead time is commit to production, not commit to merge. Including deploy time is the whole point; otherwise a team that merges fast but deploys weekly looks better than it is.

"MTTR means average incident length." Close but not quite. DORA measures specifically failed-deployment recovery -- time from a deploy-caused incident to recovery. It is a deployment-safety metric, not a general ops metric. Don't conflate it with MTTR as used in site reliability engineering, which is any-incident recovery.

"Higher deploy frequency automatically means higher quality." Deployment frequency alone is gameable -- a team can deploy hourly with a 50% failure rate. The metrics are meaningful together; any one in isolation is misleading.

"DORA works the same for any team." The definitions need calibrating. For a platform team, a "deployment" might be a Terraform apply. For a data team, a pipeline promotion. For a library team, a published release. The principles generalize; the events you count differ.

The DORA Shortcoming You Should Name​

DORA is a system-level metric, not a team-level performance review. Its most cited misuse is grading individual engineers, or ranking teams against each other across very different domains (payments vs internal tooling vs ML training). The original authors have repeatedly warned against this. The metrics answer "is our delivery system healthy?" not "who is a good engineer?" Using them for performance reviews rapidly destroys their value because teams start gaming them -- e.g., reclassifying incidents as "not deployment-related" to protect change-fail rate.

Other fair criticisms:

  • definitions require judgment calls (what counts as a deployment? a change failure?)
  • hard to compare across organizations with very different risk profiles
  • benchmark comparisons can distract from improving one application's own constraints and trend
  • SPACE (Satisfaction, Performance, Activity, Communication, Efficiency -- Forsgren et al, 2021) was introduced partly as an antidote: DORA for the system, SPACE for a team's experience

How To Use It​

Instrument the delivery metrics before you "improve" anything:

  1. Define each metric concretely for your system: what event is a deployment, what counts as a change failure, and where the timestamp comes from.
  2. Instrument automatically. Deployments should emit an event (a webhook from the pipeline, or a deployment marker to your observability tool -- see concept 15). Incidents should be tagged with whether they were deploy-triggered.
  3. Publish the trailing 30 days. Do not chase week-over-week noise; DORA's own published bands use 30- and 90-day windows.
  4. Pick one weakest metric and one intervention. Re-measure after a quarter.
  5. Re-inspect definitions every 6 months -- "what counts as a change failure" drifts silently as tooling changes.

Check Yourself​

  1. Name the current five DORA delivery metrics and group each as throughput or instability.
  2. What is the single most common misuse of the DORA metrics, and what damage does it cause?
  3. If your change-fail rate went from 5% to 25% after adopting canary rollouts, what probably changed in your definition, not your system?
  4. Why is SPACE not a replacement for DORA?

Mini Drill or Application​

Choose a service you work on or contribute to. In one page, write:

  • your operational definition of a "deployment" and a "change failure"
  • the current value of all five metrics (rough estimate is fine)
  • the one metric you would attack first and the one intervention you would make
  • the shortcoming you would refuse to use these metrics for

Bring this to a teammate or mentor. The disagreement over definitions is the lesson.

See also (external)​

Source Backbone​

CI/CD behavior must be checked against official tool docs, but these books provide the durable release-engineering backbone.