DORA Metrics: The Complete Guide to Measuring DevOps Performance
Free DevOps Audit Checklist
Get our comprehensive checklist to identify gaps in your infrastructure, security, and deployment processes
What DORA Metrics Actually Measure
The DORA (DevOps Research and Assessment) metrics come from years of research surveying tens of thousands of engineers. They boil software delivery performance down to four numbers. Two measure throughput (how fast you ship) and two measure stability (how safely you ship). The insight that made DORA famous: high performers do not trade speed for stability. They get both, because the same practices that make deployments frequent also make them safe.
Here are the four metrics and the rough thresholds that separate elite from low performers:
- Deployment Frequency: elite teams deploy on-demand, multiple times per day. Low performers deploy between once per month and once every six months.
- Lead Time for Changes: elite is under one hour from commit to production. Low is between one and six months.
- Change Failure Rate: elite sits at 0-15%. Low performers see 40-60% of changes cause a degraded service.
- Mean Time to Recovery (MTTR): elite recovers in under one hour. Low performers take a week or more.
How to Measure Each Metric
Deployment Frequency
Count production deployments over a fixed window. The cleanest source is your CI/CD system. If you use GitHub Actions, query the deployments API or count successful runs of your deploy workflow. A simple approach: tag every production deploy with a git tag or a deployment record, then count tags per week.
gh api /repos/OWNER/REPO/deployments \
--jq '[.[] | select(.environment=="production")] | length'Do not count staging or preview deploys. Only production traffic counts.
Lead Time for Changes
This is the elapsed time between a commit being authored and that commit running in production. Capture two timestamps: the commit time (from git) and the production deploy time. The median across all changes in the window is your lead time. Use the median, not the mean, because a single stale branch merged after two months will wreck an average.
Change Failure Rate
Divide the number of deployments that caused a failure (rollback, hotfix, or incident) by the total number of deployments. The hard part is defining a failure consistently. A workable rule: if a deploy triggered a rollback or an incident ticket within 24 hours, it counts as a failure. Link your incident tool (PagerDuty, Opsgenie) to the deploy that preceded the alert.
Mean Time to Recovery
Measure from the moment an incident is detected to the moment service is restored. Pull start and resolve timestamps from your incident management tool. Track the median recovery time per month.
Need DevOps help?
InstaDevOps provides expert DevOps engineering starting at $2,999/mo. Skip the hiring headache.
Book a free 15-min call →How to Improve Each Metric
Raise Deployment Frequency
Small batches are the whole game. Break large changes into independently deployable pieces. Adopt trunk-based development with short-lived branches (under a day). Put every merge to main through the same automated pipeline so deploying is a non-event. Feature flags let you merge unfinished work safely and decouple deploy from release.
Shorten Lead Time
- Cut your CI pipeline runtime. If a build takes 40 minutes, parallelize test suites and cache dependencies to get under 10.
- Eliminate manual approval gates that add hours of waiting for changes that are already tested.
- Automate the path from merge to production so nobody has to run a manual deploy script at 5pm.
Lower Change Failure Rate
Invest in a test suite you trust, run it on every commit, and add a canary or blue-green rollout so a bad deploy hits 5% of traffic before 100%. Automated rollback on health-check failure turns a potential incident into a two-minute blip. Progressive delivery is the single biggest lever here.
Cut MTTR
Fast recovery is mostly about observability and rehearsal. Ensure every service emits structured logs, metrics, and traces so you can find the fault quickly. Write runbooks for common failure modes. Make rollback a one-command operation. Practice incident response with game days so the first real incident is not the first time your team runs the playbook.
A Fifth Signal: Reliability
Recent DORA research added reliability as a fifth measure, capturing how well your service meets its operational targets (availability, latency, and error budgets). It is less a single number and more a check that throughput gains are not quietly eroding the user experience. If you already run service level objectives, you have most of what you need. Track whether you are meeting your SLOs alongside the four core metrics, and treat a burning error budget as a signal to slow feature work and invest in stability. Teams that ignore this often show great deployment frequency while customers quietly churn over slow, flaky experiences.
Common Mistakes When Adopting DORA
Do not weaponize the metrics against individuals. DORA measures the system, not people, and turning deployment frequency into a personal KPI produces gaming, not improvement. Do not chase a single metric in isolation either; pushing deployment frequency while ignoring change failure rate just ships bugs faster. Track all four together and watch the trend over weeks, not the absolute number on any given day.
Start simple. You do not need a fancy platform. A weekly spreadsheet pulling four numbers from git and your incident tool beats an elaborate dashboard nobody looks at. Once the habit sticks, automate the collection.
Many teams find that the bottleneck to elite performance is not knowing the metrics but having the platform engineering capacity to fix the pipeline, add progressive delivery, and build observability. If your team is stretched thin, a managed DevOps service can build the delivery pipeline and observability stack that make elite DORA numbers achievable, while your engineers stay focused on product. A fractional senior engineer on a monthly retainer is often enough to move a team from low to high performer within a quarter.
Get Expert Help Improving Your DORA Metrics
InstaDevOps puts a senior DevOps engineer on your team on retainer to build the CI/CD pipelines, progressive delivery, and observability that drive elite DORA performance. Plans start at $2,999/mo (Startup) and $4,999/mo (Business), with work typically starting within about 48 hours. Book a free 15-minute call to map out your path to faster, safer delivery.
Ready to Transform Your DevOps?
Get started with InstaDevOps and experience world-class DevOps services.
Book a Free CallNever Miss an Update
Get the latest DevOps insights, tutorials, and best practices delivered straight to your inbox. Join 500+ engineers leveling up their DevOps skills.