DORA Metrics

The four delivery metrics from DORA research that distinguish elite from low performers. Measurable, actionable, and tied to business outcomes.

Overview

What DORA is

DORA (DevOps Research and Assessment) is a research program founded by Nicole Forsgren, Jez Humble and Gene Kim in ~2014, acquired by Google in 2018 and now run as part of Google Cloud. The annual State of DevOps Report has 9+ years of survey data from tens of thousands of respondents across every industry.

The DORA framework names four metrics that statistically distinguish high-performing software teams, as defined in the Accelerate book and on dora.dev.

The four keys

Deployment Frequency — How often the organization successfully releases to production. A counter, not a duration — Multiple per day to less than once per six months
Lead Time for Changes — Time from code committed to code running in production; includes review, build, test and deploy time — Less than one hour to more than six months
Change Failure Rate — Percentage of deployments that cause a failure in production: incident, rollback or hotfix required — 0-15% (elite) to 46-60% (low)
Mean Time to Restore (MTTR) — Time to restore service when an incident occurs — Less than one hour (elite) to between one week and one month (low)

> [!IMPORTANT] Accelerate's key finding: high-performing teams excel at BOTH throughput and stability simultaneously. The "speed vs stability" trade-off is a myth at the team level: teams that ship more often have FEWER incidents, not more.

Performance bands

The classic four-band model, as given in the 2024 State of DevOps Report framing:

Elite — On-demand, multiple deploys per day — Less than one day — 0-15% — Less than one hour
High — Between once per day and once per week — Between one day and one week — 16-30% — Less than one day
Medium — Between once per week and once per month — Between one week and one month — 16-30% — Between one day and one week
Low — Between once per month and once every six months — Between one month and six months — 46-60% — Between one week and one month

> [!NOTE] The 2025 report introduces an Archetype framework that replaces the four bands with cluster analysis. The classic bands remain useful for maturity assessment.

The fifth metric: Reliability

Added in 2021 and refined since: does the service meet the customer's SLOs? The Accelerate research team added it because velocity plus stability still leaves a gap when measured services don't actually meet user expectations.

Why this matters in interviews

DORA metrics are the LINGUA FRANCA of senior DevOps conversations.

Recite the four keys without notes
Quote band thresholds: elite vs high vs medium vs low
Explain why Accelerate found speed and stability are NOT trade-offs
Apply DORA to diagnose a team's performance bottleneck

Key concepts

Deployment Frequency: How often production receives a successful release. Elite teams: multiple per day (often per hour for hyperscale). The Accelerate research finds this metric correlates strongly with overall organizational performance.
Lead Time for Changes: Wall-clock time from commit-to-main to running-in-production. Includes code review, CI build, test, deploy. Elite: < 1 day. The non-obvious lever is review latency — many teams have fast pipelines but slow PRs.
Change Failure Rate: Percentage of deploys that require unplanned remediation (rollback, hotfix, incident response). Elite: 0-15%. Counter-intuitive finding from Accelerate: faster-deploying teams have LOWER failure rates, because small changes have smaller blast radii.
Mean Time to Restore (MTTR): Wall-clock time from incident detection to restored service. Elite: < 1 hour. Driven by: observability quality, runbook coverage, on-call practice, mitigation automation, blast-radius limitation patterns (canary, feature flags).
Speed-stability is a false trade-off: Accelerate's most-cited finding: across thousands of teams, the highest performers on velocity (deploy frequency, lead time) are ALSO the highest performers on stability (change failure rate, MTTR). The reason: small batches produce small failures.
Reliability (5th metric): Added to DORA in 2021. Asks: does the service meet customer expectations (SLOs)? Velocity + stability without reliability still leaves users unhappy. Bridges DORA to SRE's SLO framework.

When to use it

Quarterly engineering reviews — DORA metrics are the right summary numbers for leadership
Hiring conversations — "what are your DORA metrics?" reveals engineering maturity in 60 seconds
Diagnosing why a transformation isn't working — which of the four keys is regressing?
Pre-incident planning — high MTTR signals lack of runbooks, observability, or response practice

Interview questions

Walk me through the four DORA metrics and the bands.
Why is "speed vs stability" a false trade-off according to DORA?
My team has 99% test coverage but Change Failure Rate is still 30%. What's wrong?
How would you start measuring DORA metrics for a team that's never measured them?