Reference guide · 4 metrics · Free
DORA Metrics Reference
The four metrics from the DORA (DevOps Research and Assessment) program that predict software delivery performance — what each one measures, how to measure it correctly, where the benchmarks come from, and the pitfalls that make teams measure the wrong thing.
This is a reference, not a tutorial. It assumes you've heard of DORA and want the specifics — definitions precise enough to implement, benchmarks you can quote in a planning meeting, and the mistakes we see teams make when they start tracking these for the first time.
Deployment Frequency
How often your team successfully releases to production.
Why it matters
High deployment frequency correlates with smaller batch sizes, lower risk per deploy, and faster feedback loops. It is both a measure of CI/CD maturity and an enabler of everything else — you cannot iterate quickly if shipping is painful.
Benchmarks
- 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
Source: Accelerate State of DevOps Report (DORA/Google Cloud)
How to measure
Count successful production deploys per service per day/week. Most CI/CD tools (GitHub Actions, GitLab CI, ArgoCD) expose this as a built-in metric. Exclude rollbacks and hotfixes from the count — they belong to Change Failure Rate.
Common pitfalls
- ✗ Counting deploys to staging as "deployments" — only production counts.
- ✗ Averaging across all services when one team deploys 10x/day and another deploys monthly — measure per-team or per-service.
- ✗ Optimizing for the number without reducing batch size — deploying once a day with a 500-line diff is not the same as deploying five times with 100-line diffs.
Lead Time for Changes
The time from code commit to that code running in production.
Why it matters
Lead time measures the friction in your delivery pipeline. Long lead times mean slow feedback, large batch sizes, and high coordination cost. Reducing it forces improvements in CI speed, test reliability, review turnaround, and deployment automation.
Benchmarks
- Elite Less than one hour
- High One day to one week
- Medium One week to one month
- Low More than one month
Source: Accelerate State of DevOps Report (DORA/Google Cloud)
How to measure
Measure from the first commit on a branch (or the merge-commit timestamp) to the timestamp of the deploy that includes it. Exclude time spent waiting for product decisions — this is an engineering pipeline metric, not a product planning metric.
Common pitfalls
- ✗ Including feature-planning time — lead time starts at code commit, not at ticket creation.
- ✗ Ignoring queue time: the CI pipeline takes 8 minutes, but the PR sits in review for 3 days. The review queue is often the dominant bottleneck.
- ✗ Not distinguishing between planned work and hotfixes — hotfixes should have a different (shorter) target.
Change Failure Rate
The percentage of production deployments that cause a failure requiring remediation (rollback, hotfix, or incident).
Why it matters
Change failure rate is the counterbalance to deployment frequency. A team deploying 10 times a day with a 30% failure rate is not high-performing — it is generating incidents faster than it ships features. The goal is high frequency and low failure rate simultaneously.
Benchmarks
- Elite Less than 5%
- High 5-10%
- Medium 10-15%
- Low More than 15%
Source: Accelerate State of DevOps Report (DORA/Google Cloud)
How to measure
Divide the number of deployments that required a rollback, hotfix, or triggered a production incident by the total number of deployments in the same period. Track per-service — an aggregate number across the org hides which services are fragile.
Common pitfalls
- ✗ Not counting "silent" failures — a deploy that degrades p99 latency by 200ms but doesn't trigger an alert is still a failure.
- ✗ Counting only rollbacks — hotfixes and config changes applied to remediate a bad deploy also count.
- ✗ Conflating infra failures (node crash, cloud outage) with change failures — change failure rate measures the risk of your code changes, not the reliability of your platform.
Mean Time to Restore (MTTR)
How long it takes to recover service after a production incident.
Why it matters
Failures are inevitable. MTTR measures how quickly you detect, respond to, and resolve them. A team with a low change failure rate but an 8-hour MTTR is one bad deploy away from a very long outage. Fast recovery requires automated detection, clear runbooks, and practiced incident response.
Benchmarks
- Elite Less than one hour
- High Less than one day
- Medium One day to one week
- Low More than one week
Source: Accelerate State of DevOps Report (DORA/Google Cloud)
How to measure
From the moment a production incident is detected (alert fires or user reports) to the moment service is restored to normal operation. Use your incident management tool (PagerDuty, Opsgenie, incident.io) as the system of record — timestamps are more reliable than human estimates in post-mortems.
Common pitfalls
- ✗ Measuring from the time the incident is declared rather than from the time the customer impact began — the gap between impact start and detection is often the largest part of MTTR.
- ✗ Counting "resolved" when the immediate fix is applied but not when the root cause is addressed — distinguish between "service restored" and "fully remediated."
- ✗ Not tracking MTTR by severity — a 2-hour average looks fine until you realize your Sev-1s take 12 hours.
Using DORA metrics well
Measure per-team, not org-wide. An org-level average hides the teams that need help and punishes the teams that don't. Each team should own its own metrics and improvement trajectory.
Optimise pairs, not individuals. Deployment frequency without change failure rate rewards recklessness. Lead time without MTTR ignores recovery capability. Always look at metrics in tension with each other.
Use them for improvement, not for performance reviews. The moment DORA metrics become a target that affects compensation, teams will game them — and the measurements become useless for the purpose they were designed for.
Benchmark against yourself first. The elite/high/medium/low tiers are useful for orientation, but your actual improvement path depends on where you are today, not where Google is.
Get the PDF
A printable reference card with all four metrics, benchmarks, and measurement checklists. Free, no drip sequence.
Want to know where your team actually stands?
The free Infrastructure Assessment includes a delivery-pipeline review — real data from your environment, not self-reported answers.
Book a 30-min call →