Software teams have argued about deployment speed versus stability for decades, but the DevOps Research and Assessment (DORA) program changed that conversation permanently. By analyzing data from thousands of technology organizations, DORA identified four concrete metrics that together separate elite-performing engineering teams from the rest — and showed that high speed and high stability are not in tension. Teams that deploy more frequently also tend to recover from failures faster and ship fewer defects. Understanding what these metrics measure, and how to track them systematically, is one of the highest-leverage investments a CI/CD-mature team can make.
Image: File:Containerized Continuous Deployment Pipeline 2018.png — DDuvall (WMF) (CC BY-SA 2.5), via Wikimedia Commons
The Four DORA Metrics Explained
DORA's research distilled software delivery performance into four metrics that together cover the two dimensions teams care about most: throughput (how quickly you deliver) and stability (how reliably you maintain quality).
1. Deployment Frequency measures how often your team deploys to production. Elite teams deploy on demand — sometimes multiple times per day. Low performers deploy once per month or less. This metric is a leading indicator of team autonomy, test coverage confidence, and pipeline automation maturity. If deployment requires a calendar invite and a CAB approval, your deployment frequency is compressing all your risk into rare, large batches.
2. Lead Time for Changes measures the elapsed time from a code commit being merged to that code running in production. This covers the entire value stream: CI pipeline, review gates, staging validation, and the actual deployment step. Elite performers achieve lead times under one hour. Long lead times signal bottlenecks — often in manual gates, environment dependencies, or insufficient test parallelization.
3. Change Failure Rate measures the percentage of deployments that result in a degraded service, requiring a hotfix, rollback, or patch. Elite teams see change failure rates below 5%. This metric rewards investment in automated testing, feature flags for safe rollout, and canary or blue-green deployment strategies. A low change failure rate means your pipeline catches problems before users do.
4. Mean Time to Restore (MTTR) measures how long it takes to recover service after an incident. This is not just an operations metric — it reflects pipeline readiness to roll back, observability tooling quality, on-call runbook clarity, and team cohesion under pressure. Elite teams restore in under one hour. Teams with opaque systems and fragile rollback procedures routinely take days.
DORA Performance Tiers: Where Does Your Team Stand?
| Performance Tier | Deployment Frequency | Lead Time for Changes | Change Failure Rate | MTTR |
|---|---|---|---|---|
| Elite | On-demand (multiple/day) | < 1 hour | 0–5% | < 1 hour |
| High | Daily to weekly | 1 day – 1 week | 5–10% | < 1 day |
| Medium | Weekly to monthly | 1 week – 1 month | 10–15% | 1 day – 1 week |
| Low | Monthly or less | 1 month – 6 months | 15–46%+ | More than 1 week |
How to Actually Implement DORA Measurement
Many teams commit to tracking DORA metrics and then fail to sustain it because they rely on manual data collection or poorly instrumented systems. Here is a practical implementation approach:
Deployment Frequency: Instrument your CI/CD platform to emit a deployment event every time a release reaches production. Most platforms (GitHub Actions, GitLab CI, Jenkins, CircleCI) support webhook or API event streams. Route these events to your observability stack or a purpose-built DORA dashboard tool. Count only production deployments, not staging pushes.
Lead Time for Changes: This requires linking your version control system to your deployment events. The start timestamp is when the commit (or PR merge) happened; the end timestamp is when that commit first reached production. Tools like LinearB, Sleuth, or custom queries against your git log and deployment records can compute this automatically. Watch for cherry-picks and hotfix branches that short-circuit the normal flow.
Change Failure Rate: You need a definition of "failure" that your team agrees on before you start measuring. Common definitions include: any rollback within 24 hours of deploy, any P0/P1 incident within 1 hour of deploy, or any hotfix release tagged as incident-related within 48 hours. Automate the tagging or it will be inconsistently applied.
Mean Time to Restore: Tie your incident management system (PagerDuty, OpsGenie, Incident.io) to your deployment data. MTTR is measured from the moment a service degrades (alert firing or incident declared) to the moment it is confirmed restored. Automating this requires your alerting system to track incident duration and your team to close incidents promptly when service restores.
Common Mistakes Teams Make When Adopting DORA
DORA metric adoption fails in predictable ways. The most common traps:
Optimizing metrics instead of the system: Teams that make DORA metrics a performance evaluation tool quickly learn to game them. Deployment frequency rises because teams split tiny changesets; MTTR drops because incidents get closed prematurely. Treat DORA as a diagnostic tool for the team's own improvement conversations, not as a management scorecard.
Ignoring context: A payment processing system and an internal tooling service have legitimately different risk tolerances. Comparing their DORA metrics raw is misleading. Set tier targets appropriate to service criticality and team maturity, and trend within each service over time rather than comparing across services.
Starting with MTTR and ignoring deployment frequency: MTTR is the hardest metric to move without first improving the others. Low deployment frequency means large deployments, which means harder-to-diagnose failures and slower rollbacks. Getting to high-frequency deploys is the foundation that makes MTTR improvements possible.
Skipping the fifth metric — reliability: DORA's more recent research introduced a fifth metric, reliability, measured as service availability meeting defined SLOs. This rounds out the picture: a team could technically score well on the four throughput/stability metrics while running at 95% availability, which is often unacceptable for production services.
Image: File:Devops.png — Rajiv.Pant (CC BY 3.0), via Wikimedia Commons
Tooling That Supports DORA Tracking
A small ecosystem of tools now builds DORA dashboards directly from your existing CI/CD and incident management integrations. Sleuth connects to GitHub/GitLab, your deployment system, and your incident tool to auto-compute all four metrics. LinearB focuses on developer efficiency metrics with DORA built in. Four Keys is Google's own open-source reference implementation built on BigQuery and Looker Studio — a good option if you want to self-host and customize without ongoing SaaS cost. Harness and GitLab Ultimate include DORA dashboards natively if you are already on those platforms.
For teams that prefer to build their own, the data model is relatively simple: a deployments table, an incidents table, a commits table, and the four computed metrics derivable from joins and timestamp arithmetic. The hardest part is consistently capturing the deployment and incident events with correct timestamps and service/environment tags.
Frequently Asked Questions
Are DORA metrics only relevant for large engineering organizations?
No — the DORA framework applies to any team shipping software to production. In fact, small teams often find it easier to start because they have fewer systems to instrument and can reach agreement on definitions faster. The performance tier benchmarks are based on organizations of all sizes. A two-person startup can be an elite performer; a 500-person engineering org can be a low performer. The metrics measure the system, not the headcount.
How long does it take to move from Low to High performer on DORA?
DORA's research and practitioner experience suggest that meaningful tier movement typically requires 6–18 months of focused effort. Teams that see faster progress usually start by dramatically increasing test coverage and automating their deployment pipeline — which simultaneously improves deployment frequency, lead time, and change failure rate. MTTR improvements tend to follow once the team has confidence to deploy frequently and can identify and roll back specific commits quickly.
Should we make DORA metrics public within the company?
This depends heavily on your organizational culture. Public visibility creates accountability and can inspire improvement, but it also creates pressure to optimize metrics rather than the underlying system. Most teams that succeed with DORA treat the metrics as a team-owned diagnostic tool, reviewed in retrospectives and shared voluntarily — rather than a top-down performance dashboard reviewed by management. Psychological safety is a prerequisite for honest measurement.
The Bottom Line
DORA metrics give engineering teams a common, evidence-grounded language for discussing software delivery performance. We recommend starting with deployment frequency and lead time for changes — both are relatively straightforward to instrument and quickly reveal where your pipeline has the most friction. Once you have a baseline, set a 90-day target for moving one tier on each metric and run a structured retrospective on what is blocking progress. The teams that get the most from DORA treat it not as a report card but as a map: a way to see clearly where they are and which direction to walk next.
Sources & References:
DORA (DevOps Research and Assessment) — dora.dev — the authoritative source for the four-metric framework and annual State of DevOps research.
Forsgren N, Humble J, Kim G. Accelerate: The Science of Lean Software and DevOps. IT Revolution Press, 2018 — the foundational book synthesizing the DORA research program.
Disclaimer: This article is for informational purposes only. Technology landscapes change rapidly; verify information with official sources before making technical decisions.