Skip to content

DORA Metrics Explained: The Four Keys to Delivery Performance

July 18, 2026·2 min read
engineeringdevopsdorametricssoftware delivery

What DORA metrics are

The DORA metrics come from years of research (the DevOps Research and Assessment program) into what separates high-performing software teams from the rest. The finding: four measurable signals predict delivery performance remarkably well. Two are about speed, two are about stability — and great teams score well on both, not one at the expense of the other.

You can compute your own from real numbers in the DORA metrics calculator; this post explains what each one means.

The four metrics

1. Deployment Frequency (speed)

How often you ship to production. Elite teams deploy on demand — multiple times per day; lower performers ship weekly to monthly. Frequent, small deploys are less risky than rare, giant ones, because each change is easier to review, test, and roll back.

2. Lead Time for Changes (speed)

How long a commit takes to reach production. Elite: under an hour. This measures the whole pipeline — review, CI, and release — so a bad number often points at slow reviews or a flaky build rather than slow coding.

3. Change Failure Rate (stability)

The share of deployments that cause a failure needing remediation (a rollback, hotfix, or patch). Elite teams sit around 0–15%. A high rate signals gaps in testing or review; a suspiciously low rate sometimes means you just aren't shipping much.

4. Time to Restore Service (stability)

When something breaks, how fast you recover. Elite: under an hour. This rewards good observability, fast rollbacks, and practiced incident response — the ability to recover often matters more than never failing.

Reading them together

The two axes tell a story:

  • Fast + stable → elite. Small, frequent changes with quick recovery.
  • Fast + unstable → you're shipping recklessly; invest in tests and rollbacks.
  • Slow + stable → you're careful but rigid; batch sizes are probably too big.
  • Slow + unstable → the danger zone; usually a process and tooling problem, not a people problem.

Never optimize one metric in isolation. Pushing deployment frequency up while ignoring change failure rate just ships bugs faster.

How to improve without gaming the numbers

  • Shrink batch size. Smaller PRs → faster reviews, lower failure rate, easier rollbacks. This single habit moves all four metrics.
  • Automate the pipeline. CI/CD, automated tests, and one-click (or automatic) deploys cut lead time and failures at once.
  • Invest in recovery, not just prevention. Feature flags, fast rollbacks, and good alerting shrink time-to-restore — and make shipping less scary.
  • Measure trends, not vanity snapshots. A team improving month over month beats a team with one great week.

Try it with your numbers

Plug in your deploys, lead times, incidents, and recovery times to see where you land against the elite/high/medium/low bands: DORA metrics calculator.

The goal isn't a perfect scorecard — it's a shared, honest picture of where your delivery process is slow or fragile, so you know what to fix next.