DORA metrics: the four keys, explained

The DORA (DevOps Research and Assessment) program groups delivery performance into four metrics:

• Deployment frequency — how often you release to production.
• Lead time for changes — how long a change takes to go from committed to running in production.
• Change failure rate — the share of deployments that cause a failure needing remediation.
• Time to restore service — how long it takes to recover when a failure does happen.

The first two measure throughput; the last two measure stability. They’re designed to be read together — velocity that comes at the cost of a rising failure rate isn’t real improvement.

DORA classifies teams into Elite / High / Medium / Low performance tiers against its published cut points. The canonical framing: elite teams deploy on demand (multiple times per day) with a lead time under a day, keep change failure rate low, and restore service in under an hour; low performers deploy infrequently with lead times measured in months. DevPerform bands the four keys against this canonical State-of-DevOps operationalization, using the widely cited 15% / 30% cuts for change failure rate.

The bands are a shared vocabulary, not a scoreboard. A team shipping a regulated medical device and a team shipping a web app have very different legitimate baselines.

• Deployment frequency is not merge frequency. Counting merged PRs approximates release cadence only if every merge ships. If you deploy in batches or behind release trains, wire up a real deploy signal so the number reflects production, not the merge queue. (DevPerform supports both a no-setup “merges” mode and an “actions” mode driven by real deploy events.)
• Change failure rate is not test pass rate. It counts production incidents per deploy, not CI results.
• The four keys are a set. Optimizing deployment frequency while ignoring failure rate just moves the problem. Always read speed and stability together.
• Lead time has two common definitions. Be clear whether you mean commit-to-deploy or PR-open-to-merge; they answer different questions.

Lead time and cycle time overlap but aren’t the same: cycle time zooms into the pull-request lifecycle (coding, pickup, review), which is where day-to-day flow improvements happen, while DORA lead time spans all the way to production. Teams typically use cycle-time phases to find the bottleneck and DORA to track the outcome.

DevPerform computes all four DORA metrics from your ingested GitHub, GitLab, or Bitbucket data — every metric works for every provider, with no agents or CI changes. You can explore the demo to see a DORA dashboard with live bands, or benchmark a public repo for a quick read on delivery performance.