What Are DevOps Metrics — And Why Most Teams Measure the Wrong Things
Every engineering team measures something. The problem is that most teams measure the wrong things.
Lines of code written. Story points completed. Number of tickets closed. PRs merged per week. These are activity metrics — they tell you your team is busy. They tell you nothing about whether your team is effective.
DevOps metrics exist to answer a different question: are we getting better at delivering reliable software, faster, with fewer failures? That question has a precise, research-backed answer — and it starts with understanding DORA metrics.
DORA metrics — developed by the DevOps Research and Assessment team led by Dr. Nicole Forsgren — are the most rigorously validated framework for measuring software delivery performance ever produced. They emerged from six-plus years of research involving tens of thousands of engineering teams across industries, and the results are published in the landmark book Accelerate.
This guide covers what DORA metrics are, how to implement them, what they miss, and which additional DevOps metrics high-performing teams track beyond DORA to get the complete picture of engineering health.
The Four Core DORA Metrics Explained
DORA devops research identified four key metrics that consistently differentiate elite engineering teams from average and low performers. Together, these DORA devops metrics measure two things: speed of delivery and stability of systems. Critically, DORA research proved what many engineering leaders long suspected — speed and stability are not a trade-off. The best teams have both.
DORA Metric 1: Deployment Frequency
What it measures: How often your team deploys code to production.
Why it matters: Deployment frequency is the heartbeat of a high-performing engineering team. Teams that deploy frequently ship smaller changes, which means lower risk per deployment, faster feedback from real users, and dramatically easier debugging when something goes wrong.
Deployment frequency is also a forcing function for cultural maturity. You cannot deploy frequently if your deployment process is manual, fragile, or politically fraught. High deployment frequency requires automated pipelines, psychological safety, shared ownership, and trust — all the hallmarks of a healthy DevOps culture.
DORA performance benchmarks:
- Elite: Multiple deploys per day
- High: Between once per day and once per week
- Medium: Between once per week and once per month
- Low: Less than once per month
What kills deployment frequency: Manual approval gates, long-running test suites, fear of production, lack of feature flagging, monolithic architectures that require full-system deploys.
How to improve it: Invest in CI/CD automation, implement feature flags (so code can be deployed without being activated), decompose monoliths into independently deployable services, and run blameless post-mortems to reduce fear of production.
DORA Metric 2: Lead Time for Changes
What it measures: The time from a code commit to that code running in production.
Why it matters: Lead time for changes is the most comprehensive single indicator of engineering system health. It captures the cumulative effect of everything that slows down delivery: slow test suites, manual review steps, environment bottlenecks, long approval queues, and organizational friction.
If your deployment frequency tells you how often you ship, lead time tells you how fast you can respond to the world — to customer feedback, to competitor moves, to production bugs.
DORA performance benchmarks:
- Elite: Less than one hour
- High: Between one day and one week
- Medium: Between one week and one month
- Low: Between one month and six months
What kills lead time: Code review bottlenecks (PRs sitting unreviewed for days), slow CI pipelines, environment provisioning delays, complex compliance and change management processes, large batch sizes.
How to improve it: Reduce PR size (smaller PRs get reviewed faster and have fewer bugs), parallelize CI pipeline stages, automate environment provisioning with Infrastructure as Code, and replace manual change advisory boards with automated compliance checks.
DORA Metric 3: Change Failure Rate
What it measures: The percentage of deployments that result in a production failure requiring remediation — a hotfix, rollback, or patch.
Why it matters: Change failure rate is your quality signal within the DORA metrics framework. It tells you how often your team ships something broken. Importantly, the DORA research shows that elite teams don't achieve low change failure rates by deploying less frequently — they achieve it by deploying smaller, better-tested changes, more often.
A high change failure rate is expensive in multiple ways: direct cost of incident response, indirect cost of engineering time diverted from new features, and reputational cost of reliability failures with customers.
Tracking the right DevOps metrics helps teams improve deployment speed, reliability, and overall performance. Join our DevOps Course to learn DORA metrics, CI/CD best practices, and real-world DevOps workflows.
DORA performance benchmarks:
- Elite: 0–5%
- High: 5–10%
- Medium/Low: 10–15% and above
What drives change failure rate up: Insufficient automated testing, large and infrequent deploys, lack of observability (can't detect failures fast), no feature flagging (can't safely separate deployment from activation), poor code review culture.
How to improve it: Invest in automated testing at every level (unit, integration, contract, end-to-end), implement progressive delivery patterns (canary releases, blue-green deployments), add pre-production environment parity, and track which types of changes fail most often so you can target testing investment precisely.
DORA Metric 4: Mean Time to Restore (MTTR)
What it measures: How long it takes to restore service after a production failure.
Why it matters: No system achieves zero failures. The question is not whether you will have incidents — it is how fast you can detect and resolve them when they happen. MTTR is your resilience metric within the DORA framework.
MTTR is driven by three sub-capabilities: detection speed (how fast you know something is broken), diagnosis speed (how fast you identify what's broken), and recovery speed (how fast you can fix or roll back).
DORA performance benchmarks:
- Elite: Less than one hour
- High: Less than one day
- Medium: Between one day and one week
- Low: More than one week
What kills MTTR: Poor observability (flying blind when incidents occur), complex rollback procedures, lack of runbooks, siloed knowledge (only one person knows how to fix it), slow escalation paths, and alert fatigue that causes engineers to ignore alarms.
How to improve it: Build robust observability (metrics, logs, distributed traces — OpenTelemetry is the current standard), write and maintain runbooks for common failure modes, practice incident response drills, implement automated rollback capabilities, and reduce alert noise so real alerts get immediate attention.
The 2024–2025 DORA Update: A Fifth Metric
The DORA devops research team added a fifth metric in their more recent work:
Reliability (Operational Performance)
What it measures: Whether teams are meeting their defined reliability targets — typically expressed as SLOs (Service Level Objectives) covering availability, latency, and error rates.
Why it matters: The four original DORA devops metrics are process metrics — they measure how you work. Reliability is an outcome metric — it measures whether your customers are actually experiencing the service quality you intend to deliver.
Tracking SLO compliance alongside the original four DORA metrics creates a complete picture: you can ship fast and recover quickly, but if you're consistently missing your reliability targets, something structural in your architecture or operations is broken.
Beyond DORA: The DevOps Metrics That Complete the Picture
DORA metrics are the foundation of any serious engineering measurement system. But they don't tell the whole story. High-performing engineering teams track additional DevOps metrics across three categories: developer experience, system health, and business alignment.
Developer Experience Metrics
These DevOps metrics measure how it feels to be an engineer on your team — and that feeling is a leading indicator of future performance.
Developer Satisfaction Score (DevEx)
Measured via regular pulse surveys (quarterly at minimum), developer satisfaction captures sentiment around tooling quality, process friction, psychological safety, clarity of purpose, and work-life balance. The DevEx framework — published by researchers Abi Noda, Margaret-Anne Storey, Nicole Forsgren, and Michaela Greiler — formalizes this into a repeatable measurement system.
Teams that ignore developer satisfaction experience compounding talent attrition and degrading productivity before any traditional metric signals a problem.
Build and Test Pipeline Duration
How long does it take from git push to a green CI signal? This directly impacts developer flow state. Research consistently shows that pipelines longer than ten minutes cause engineers to context-switch — and context switching is the productivity killer most engineering leaders underestimate.
Target: under ten minutes for the standard developer feedback loop. Under two minutes for the most common paths (unit tests, linting, type checking).
PR Review Cycle Time
Time from PR opened to PR merged. This measures collaboration velocity and code review health. Long PR cycle times create merge conflicts, stale branches, and developer frustration. They are also a leading indicator of deployment frequency problems — you cannot deploy frequently if your code review process takes days.
Target: median under four hours for standard PRs.
Anything over 24 hours is a system dysfunction.
Toil Percentage
Coined by Google's Site Reliability Engineering team, toil refers to repetitive, manual, automatable work that doesn't improve the system. Every hour an engineer spends on toil is an hour not spent on work that compounds.
Google's SRE team targets keeping toil below 50% of engineering time.
Elite teams target below 20%. Track it via periodic time-audit surveys asking engineers to categorize their last week of work.
System Health and Reliability Metrics
These DevOps metrics sit below DORA and provide the diagnostic resolution needed to understand why your DORA numbers look the way they do.
Error Budget Consumption
Error budgets — the operational concept that sits alongside SLOs — measure how much of your allowed unreliability you've consumed in a given period. If your SLO is 99.9% availability, your monthly error budget is approximately 43 minutes of downtime.
Error budget consumption is a forcing function for reliability investment. When a team burns through its error budget, new feature work stops and reliability work takes over. This creates natural, self-regulating pressure toward quality without requiring top-down mandates.
Incident Volume and Severity Distribution
Track the total number of incidents per month, broken down by severity level. More important than the absolute number is the trend and the distribution — are you mostly dealing with low-severity disruptions, or are high-severity incidents recurring? Recurring high-severity incidents in the same system are a strong signal of unaddressed technical debt or architectural fragility.
Alert-to-Incident Ratio
What percentage of alerts that fire actually correspond to a real user-impacting incident? A low ratio (many alerts, few real incidents) indicates alert fatigue — one of the most dangerous conditions in engineering operations because it causes engineers to start ignoring alarms, including real ones.
Target: above 50% signal-to-noise ratio. Elite teams push toward 80%+.
Test Coverage and Test Reliability
Not just percentage coverage (which is easily gamed), but the reliability of your test suite — what percentage of test runs complete without flaky failures unrelated to actual code changes? Flaky tests are a form of alert fatigue at the CI level. Engineers who learn to ignore flaky tests lose their ability to trust the test suite entirely.
Business Alignment Metrics
These DevOps metrics connect engineering performance to business outcomes — the connection that engineering leaders must be able to articulate to executive stakeholders.
Feature Cycle Time (Concept to Customer)
Lead time for changes measures technical throughput. Feature cycle time measures end-to-end value delivery — from the moment a feature is conceived to the moment it reaches users. This includes product discovery, design, development, deployment, and activation via feature flags.
This is the metric that connects DevOps performance to product velocity.
Deployment Success Rate by Team
Disaggregated by team, this DevOps metric helps identify which teams are thriving and which are struggling — enabling targeted platform investment or enabling team intervention without requiring top-down performance reviews.
Cost Per Deployment
Infrastructure and pipeline costs divided by deployment count. As deployment frequency increases with automation, cost per deployment should decrease. If it's not, your automation investment is not scaling efficiently.
How to Implement DORA Metrics: A Practical Starting Guide
Measuring DORA metrics for the first time feels daunting. It isn't. Here is a straightforward path to getting your first readings within 30 days.
Step 1: Define your production boundary clearly. What counts as "deployed to production"? The definition must be consistent across teams. For some organizations this is a merge to main with automatic deploy. For others it's a manual promotion to a production environment. Define it once, apply it everywhere.
Step 2: Start with deployment frequency and lead time. These two DORA metrics are the easiest to instrument from version control and deployment logs. GitHub, GitLab, and most CI/CD platforms expose the raw data. Tools like LinearB, Jellyfish, Haystack, and Faros AI provide purpose-built DORA metrics dashboards if you want to skip the instrumentation work.
Step 3: Instrument change failure rate via incident tracking. Link your incident management tool (PagerDuty, OpsGenie, FireHydrant) to your deployment logs. A change failure is any incident that is causally linked to a recent deployment. Automate the tagging where possible; manually review and tag the rest.
Step 4: Measure MTTR from your incident management system. Most incident management platforms calculate MTTR natively. Pull it into your central engineering metrics dashboard and review it weekly.
Step 5: Baseline, then set realistic improvement targets. Don't compare your numbers to the DORA benchmarks and declare crisis. Baseline where you are today, identify the single biggest bottleneck (usually lead time or deployment frequency), and set a 90-day improvement target. Compound from there.
DORA Metrics: Common Mistakes and How to Avoid Them
Treating DORA metrics as performance reviews for individuals.
DORA metrics are team and system metrics. Using them to evaluate individual engineers destroys psychological safety and causes gaming — engineers will optimize for the metric rather than for real improvement.
Measuring deployment frequency without controlling for deployment risk.
A team that deploys 50 times per day by splitting work into micro-commits that bypass testing is not an elite team — it's a liability. Deployment frequency only matters when paired with change failure rate and MTTR.
Ignoring the difference between mean and percentile.
Mean MTTR of two hours sounds fine. If your P95 is 18 hours, you have a serious problem that the mean is hiding. Always look at distribution, not just central tendency.
Setting targets without understanding current bottlenecks.
Telling a team to cut lead time by 50% without diagnosing where the time is being lost is management theater. Instrument your pipeline, find the actual constraint, and invest there.
Treating DORA as a one-time measurement exercise.
DORA metrics are only valuable as a continuous signal. Measure them weekly, review trends monthly, and make them a standing agenda item in engineering leadership meetings.
Frequently Asked Questions About DORA Metrics
What does DORA stand for in DevOps?
DORA stands for DevOps Research and Assessment. It is the research team — originally founded by Dr. Nicole Forsgren, Jez Humble, and Gene Kim — that conducted the multi-year research program identifying the four key metrics that predict software delivery performance. The DORA research program is now hosted by Google.
Are DORA metrics applicable to small teams?
Yes. DORA metrics devops research included teams of all sizes, from small startups to large enterprises. The benchmarks are relative — a five-person team should not compare itself to Netflix in absolute terms, but the directional improvement signal is universally valid.
What tools can I use to measure DORA metrics?
Purpose-built tools include LinearB, Jellyfish, Haystack, Faros AI, and Sleuth. Platforms like GitHub, GitLab, and Azure DevOps have built-in DORA metrics dashboards. You can also build your own instrumentation using deployment logs, incident management APIs, and a BI tool like Metabase or Grafana.
How do DORA metrics relate to SRE (Site Reliability Engineering)?
DORA devops metrics and SRE practices are highly complementary. SRE contributes MTTR reduction through observability, runbooks, and error budget management. DORA metrics provide the measurement framework that makes SRE investment legible to engineering leadership and business stakeholders.
Can DORA metrics be gamed?
Yes, and they will be if leadership uses them punitively. The antidote is to use DORA metrics as diagnostic tools for systemic improvement, never as individual performance metrics. Pair them with developer experience surveys and business outcome metrics to create a measurement system that is hard to game without also genuinely improving.
What is a good DORA metric score for a mid-sized engineering team?
"Good" depends heavily on your starting point, industry, and system complexity. As a general target for a team beginning its DevOps metrics journey: aim for deployment frequency of at least once per week, lead time under one week, change failure rate below 15%, and MTTR under one day within your first year of focused improvement. Those numbers put you solidly in the "high" DORA performance category — ahead of the majority of engineering organizations globally.
The Bottom Line on DORA and DevOps Metrics
DORA metrics are not a management fad. They are the product of rigorous, peer-reviewed research, and they have been replicated across thousands of engineering teams in every industry. The conclusion of that research is unambiguous: teams that score well on DORA devops metrics deliver better business outcomes, experience less burnout, and build more reliable products.
But DORA metrics are a starting point, not a destination. The engineering teams that genuinely outperform over sustained periods combine DORA metrics with developer experience measurement, system health observability, and business alignment metrics — creating a three-dimensional picture of engineering health that DORA alone cannot provide.
Elite engineering teams rely on data-driven DevOps practices to scale efficiently. Our practical Devops Training covers DORA metrics, monitoring, automation, and performance optimization with hands-on experience.
Measure what matters. Fix the biggest bottleneck. Repeat. That is the entire discipline of DevOps metrics in two sentences. The teams that internalize this — and protect the time and culture required to act on what the metrics reveal — are the teams that compound their advantage year over year until they are operating in a different league entirely.
