What are DORA Metrics?
Most engineering organisations have a gut feeling about how well their delivery pipeline is performing. DORA Metrics replace that gut feeling with four specific, measurable numbers - each one backed by research showing its correlation with organisational outcomes like revenue, customer satisfaction, and employee engagement.
DORA stands for DevOps Research and Assessment, a programme started by Gene Kim, Jez Humble, and Nicole Forsgren that has surveyed tens of thousands of engineers and organisations globally since 2014. Their research, published in the book Accelerate and the annual State of DevOps Report, identified four metrics that consistently separate high-performing teams from low-performing ones.
The Four Metrics
1. Deployment Frequency
How often does your team deploy to production? This is the most immediate proxy for how much value you are delivering to users and how low your deployment risk is. Teams that deploy small changes frequently have less to go wrong per release and build confidence with every successful push.
Elite: Multiple times per day
High: Once per day to once per week
Medium: Once per week to once per month
Low: Once per month to once every six months
2. Lead Time for Changes
How long does it take from a developer merging a pull request to that change running in production? Short lead times mean fast feedback loops - a bug fix reaches users quickly, a feature hypothesis gets validated sooner, and engineers spend less time waiting.
Elite: Less than one hour
High: One day to one week
Medium: One week to one month
Low: One to six months
3. Change Failure Rate
What percentage of your production deployments cause a degradation or incident requiring a hotfix or rollback? This metric directly measures the quality and testability of your delivery process.
Elite: 0-5%
High: 5-10%
Medium: 10-15%
Low: 46-60%
4. Time to Restore Service (MTTR)
When a production incident does happen, how long does it take to restore normal service? This measures your organisation's ability to detect, respond to, and recover from failures.
Elite: Less than one hour
High: Less than one day
Medium: One day to one week
Low: More than one week
Why These Four Metrics?
The DORA research shows that these four metrics fall into two dimensions: throughput (Deployment Frequency + Lead Time) and stability (Change Failure Rate + Time to Restore). High-performing teams score well on all four - the research disproved the common assumption that you have to choose between speed and stability. Elite teams are faster and more stable.
How to Measure Them in Practice
Deployment Frequency is easiest to instrument: count successful production deploys from your CI/CD pipeline. A GitHub Actions workflow can emit a metric or webhook event on every successful production deploy.
Lead Time requires timestamps at two points: when code merges to main and when that commit reaches production. Most CI/CD systems can provide both.
Change Failure Rate needs a definition of "failure". Most teams count deployments that triggered a production incident, a hotfix within 24 hours, or an explicit rollback. Correlate deploy events with incident records from your alerting tool.
Time to Restore requires incident start and end timestamps. Tools like PagerDuty and Opsgenie export this data via API.
# Example: query GitHub API for deployment frequency
# Count successful deployments to production in the last 30 days
gh api \
-H "Accept: application/vnd.github+json" \
"/repos/ORG/REPO/deployments?environment=production&per_page=100" \
| jq '[.[] | select(.created_at >= "2026-09-01")] | length'
# Output: 47 deployments in 30 days -> roughly 1.5 per day -> High performer
Using DORA Metrics to Drive Improvement
The metrics are only useful if you act on them. Low Deployment Frequency usually points to large batch releases and a fear of deploying - the fix is smaller PRs and automated testing. High Lead Time often means a slow test suite or manual approval gates that could be automated.
High Change Failure Rate is a signal that your automated test coverage has gaps or that your deployment process lacks confidence - adding pre-production integration tests and feature flags helps here. Long Time to Restore usually points to poor observability and no runbooks - investing in CI/CD rollback automation and better alerting pays off quickly.
DORA metrics give you a shared language with leadership for why engineering investments in testing, deployment automation, and DevOps practices pay off in measurable business outcomes.