DORA Metrics: How Engineering Teams Measure and Improve Software Delivery Performance

DORA metrics — Deployment Frequency, Lead Time for Changes, Mean Time to Recover, and Change Failure Rate — are the four engineering performance indicators that separate elite software teams from everyone else. Originally surfaced by the DevOps Research and Assessment (DORA) team at Google and validated across thousands of organizations in the Accelerate State of DevOps reports, these four metrics correlate directly with organizational performance: teams that score well on software delivery performance are twice as likely to exceed commercial goals compared to low performers.

For CTOs and engineering leaders, DORA metrics answer the question most business stakeholders ask and most engineering teams struggle to answer quantitatively: how fast and how safely are we shipping? They expose the true health of your delivery pipeline in ways that lines of code, sprint velocity, or story point burn-down never can. If you are building a SaaS product or scaling an existing engineering organization, understanding your DORA baseline is the first step toward systematically improving it.

This guide covers what each DORA metric actually measures, what separates elite from low-performing teams, how to collect the data without buying a dedicated tool, and the specific practices that move each metric. For the CI/CD pipeline changes that directly affect lead time and deployment frequency, see our post on DevSecOps and CI/CD pipeline security.

What Are the 4 DORA Metrics?

The four DORA metrics cover two dimensions of software delivery: throughput (how fast you ship) and stability (how reliably you ship). Throughput and stability are not a trade-off — elite teams achieve both simultaneously, which is the central finding of the Accelerate research. Low-performing teams often sacrifice stability for speed or slow down to avoid incidents; elite teams engineer both through better practices, not harder trade-offs.

• →Deployment Frequency: How often your team deploys code to production. Measures throughput velocity. Elite teams deploy on-demand — multiple times per day. Low performers deploy monthly or less frequently.
• →Lead Time for Changes: The time from a code commit being merged to it running in production. Measures throughput cycle time. Elite teams achieve less than one hour; low performers take between one month and six months.
• →Mean Time to Recover (MTTR): The average time to restore service after a production incident. Measures stability recovery. Elite teams recover in less than one hour; low performers take between one week and one month.
• →Change Failure Rate: The percentage of deployments that cause a production failure requiring a hotfix, rollback, or patch. Measures stability reliability. Elite teams maintain 0–5%; low performers see 46–60%.

Deployment Frequency: Moving from Monthly Releases to On-Demand

Deployment frequency is the single most actionable DORA metric because it is almost entirely a function of your internal practices, not external factors. Low deployment frequency is a symptom of accumulated risk: teams that deploy infrequently do so because each deployment is large, manual, and risky. The fix is to make individual deployments smaller and automated until the fear of deploying disappears.

The highest-leverage practices for improving deployment frequency are trunk-based development (all engineers merge to main frequently rather than maintaining long-lived feature branches), feature flags to decouple deployment from release, automated test suites that give you confidence to ship without manual QA gates, and a CI/CD pipeline that triggers a production deploy on every merged commit rather than on a scheduled release window.

• →Trunk-based development: Feature branches that live longer than two days slow deployment frequency because merging them creates integration debt. Trunk-based development — short-lived branches or direct commits to main with feature flags — keeps the codebase in a shippable state continuously.
• →Feature flags: Separating deployment (code in production) from release (users seeing the feature) lets you ship daily while controlling rollout independently. This is what allows a team to deploy incomplete features safely.
• →Automated test coverage: You cannot deploy frequently if each deploy requires a manual testing cycle. Automated unit, integration, and end-to-end tests are the prerequisite for high-frequency deployments.
• →Pipeline automation: If deploying requires human steps — manual approvals, environment setup, or runbook execution — each one is a cap on frequency. Automate every step that does not require human judgment.
• →Small PRs and code reviews: Large pull requests sit in review longer, accumulate merge conflicts, and carry more risk. Teams that average fewer than 400 lines per PR have deployment frequencies significantly higher than teams averaging over 1,000 lines.

Lead Time for Changes: Cutting the Code-to-Production Gap

Lead time for changes measures the elapsed time from a commit merging to main until it is deployed in production — not the time to write the code. It captures everything that happens in between: code review, CI pipeline duration, staging validation, and approval gates. Teams with long lead times are usually blocked at one or two specific points, which makes this metric diagnostic: measure the time at each stage and the bottleneck becomes obvious.

The most common lead time killers are slow CI pipelines, approval chains that require synchronous sign-off from multiple people, staging environments that are manually provisioned or shared across teams (causing queuing), and flaky tests that require re-runs. CI pipelines longer than 15 minutes are a problem: parallelizing test suites, using build caching, and running only tests affected by the change set can cut pipeline time by 60–80% in most codebases.

• →Parallelize the CI pipeline: Running unit tests, integration tests, and static analysis sequentially is the leading cause of slow lead times. Move independent stages to parallel jobs. Most CI systems — GitHub Actions, GitLab CI, CircleCI — support this natively.
• →Set code review SLAs: Unreviewed PRs sitting overnight are an invisible lead time tax. A team norm of 4-hour review windows for non-critical paths has a larger impact on lead time than most infrastructure changes.
• →Eliminate shared staging queues: If multiple teams share a staging environment and must take turns, lead time accumulates waiting for the slot. Ephemeral per-branch environments managed through Kubernetes namespaces solve this directly.
• →Automate deployment approvals for low-risk changes: Manual approval gates are appropriate for high-risk configuration changes; they add cost without benefit for routine code changes. Risk-stratify your approval process and automate the low-risk path.
• →Cache build artifacts aggressively: Rebuilding unchanged dependencies on every CI run is pure waste. Layer caching in Docker, dependency caching in your package manager, and incremental compilation all reduce pipeline time without changing your quality gates.

Mean Time to Recover: Building Incident Response That Scales

Mean Time to Recover (MTTR) measures how long it takes to restore normal service after a production incident — from the moment the incident is detected until service is restored. It is the metric most directly tied to user trust and revenue impact, and it is the one most often confused with Mean Time to Detect (MTTD). Poor MTTD hides poor MTTR: if you take two hours to detect an incident and 30 minutes to fix it, your MTTR is 2.5 hours, not 30 minutes. Improving MTTR requires addressing both detection and resolution.

Detection speed is an observability problem. Teams with comprehensive metrics, distributed tracing, structured logging, and alerting that fires on symptoms — error rate spikes, latency increases, availability drops — detect incidents in minutes rather than hours. For how to build that observability foundation, see our guide on OpenTelemetry for enterprise observability. Resolution speed is an incident response process problem: runbooks, clear ownership, blameless post-mortems, and practiced rollback procedures are the levers.

• →Symptom-based alerting: Alert on user-facing outcomes — error rate above threshold, p99 latency above threshold, availability below threshold — not on resource metrics like CPU that may or may not indicate a real problem. Symptom-based alerts catch incidents earlier and produce fewer false positives.
• →Runbooks for every critical path: An on-call engineer facing an incident at 2 a.m. should not have to figure out the fix from first principles. Runbooks with clear decision trees for the most common failure modes cut resolution time by 40–70%.
• →Rollback-first culture: For most incidents, rolling back the most recent deployment is faster than patching forward. Build confidence in your rollback mechanism by testing it outside incident drills. If rollback takes 30 minutes, that is a deployment tooling problem to fix before the next incident.
• →Blameless post-mortems: Teams that respond to incidents with blame create incentives to hide problems and avoid risky-but-important work. Blameless post-mortems that focus on process improvements surface the systemic causes that prevent recurrence.
• →Chaos engineering and game days: Practicing incident response before an incident occurs — through controlled chaos experiments or structured game days — builds the muscle memory that compresses resolution time under real pressure.

Change Failure Rate: Shifting Quality Left in Your Pipeline

Change Failure Rate (CFR) measures the proportion of deployments that cause a production failure requiring remediation — a hotfix, rollback, or emergency patch. A high CFR means your pipeline is regularly shipping defects to users, and the correlation between CFR and team performance is stark: elite performers maintain CFRs of 0–5%, while low performers consistently see 46–60%.

The root cause of high CFR is almost always insufficient pre-production quality control, not insufficient developer skill. Defects reach production when tests are incomplete, when testing environments do not replicate production conditions, when deployment procedures are manual and error-prone, or when code review focuses on style over correctness. Shifting quality left — adding checks earlier in the pipeline, before a defect can reach production — is the systematic fix.

• →Automated test coverage tied to deployment gates: The pipeline should block a deployment if new code paths are untested. Many teams have extensive test suites that are not enforced — they run but do not block. The gate is what matters.
• →Production-parity staging: Defects that only appear in production usually do so because staging did not replicate the production data volume, traffic pattern, or configuration. Closing that gap with anonymized production data copies, realistic load tests, and infrastructure parity catches more defects before they ship.
• →Canary deployments: Rolling out a change to 1–5% of traffic before a full deploy lets you measure its error rate against the previous version and abort before a defect reaches all users. This is standard practice for elite teams and has a direct, measurable effect on CFR.
• →Feature flag-based rollouts: Decoupling code deployment from feature rollout means you can disable a defective feature in seconds — effectively reducing the blast radius of any defect that escapes detection.
• →Static analysis and SAST in the PR phase: Catching defects at the code review stage — before merge — means they never enter the deployment pipeline. Tools like Semgrep, Snyk, and SonarQube running on PR creation add quality gates without slowing the main pipeline.

How to Collect DORA Metrics Without a Dedicated Tool

Most teams do not need to buy a DORA metrics platform to start measuring. The data already exists in your source control system, CI/CD pipeline, and incident management tool — it just needs to be surfaced. Start by defining deployment frequency and lead time from your Git history and CI runs: GitHub Actions and GitLab CI expose APIs that let you query deployment timestamps and pipeline durations. MTTR comes from your incident management tool — PagerDuty, Opsgenie, and equivalent platforms export incident open and close timestamps. Change Failure Rate requires tagging incidents caused by deployments versus other causes, which is best done in your post-mortem process.

• →GitHub Insights or GitLab Analytics: Both surface deployment frequency data if you tag production deployments consistently through environment events or workflow runs targeting a production environment. This costs nothing and requires only a naming convention.
• →CI pipeline timestamps: Lead time is the delta between commit timestamp and the production deployment job completion time. Export this to a shared dashboard weekly to start, then automate it once the pattern is clear.
• →PagerDuty or Opsgenie reports: Both tools export MTTR by service and by team with no custom tooling required. The 90-day rolling report gives you a stable baseline before you start targeting improvements.
• →Commercial DORA platforms: LinearB, Haystack, Cortex, and JetBrains Space automate collection and provide benchmarking against industry peers. Worth the investment once you have confirmed what you are trying to optimize — not before you have a baseline.
• →Weekly team review ritual: The first improvement lever is often just making the metrics visible. A five-minute weekly review of each metric in a team standup changes behavior before any tooling changes are needed.

DORA Metrics in the Age of AI-Assisted Development

AI code assistants — GitHub Copilot, Claude, Cursor — change the DORA metric landscape in ways the original Accelerate research did not anticipate. Deployment frequency typically increases when AI tools accelerate code production: developers ship more features faster. But this creates a specific risk for Change Failure Rate if the quality controls upstream of deployment do not scale equally fast. AI-generated code that passes automated tests but contains subtle logic errors, race conditions, or security issues will show up as production incidents — inflating CFR without any corresponding increase in deployment risk awareness on the team.

The 2025 State of DevOps report introduced a fifth DORA metric — Reliability, measuring whether services meet their stated SLOs — partly in response to this dynamic. Engineering teams scaling their AI-assisted output need to instrument reliability alongside the classic four, not just throughput metrics. Teams that use AI to generate tests alongside production code maintain lower CFRs than teams using AI only for implementation. The platform engineering discipline of building standardized pipelines, guardrails, and quality gates becomes more important as individual developer output velocity increases — because it is the platform that enforces the quality bar across all that additional output.

Frequently Asked Questions

What are the 4 DORA metrics?

The four DORA metrics are Deployment Frequency (how often you deploy to production), Lead Time for Changes (time from commit to production), Mean Time to Recover (time to restore service after an incident), and Change Failure Rate (percentage of deployments that cause a production failure). They were established by the DevOps Research and Assessment team at Google through annual surveys of thousands of software organizations and form the empirical foundation of the Accelerate book.

What is considered elite DORA performance?

According to the Accelerate State of DevOps research, elite performers deploy on-demand (multiple times per day), achieve lead times under one hour, recover from incidents in under one hour, and maintain a change failure rate between 0 and 5 percent. These benchmarks are achievable for most teams but require deliberate investment in CI/CD automation, observability, and testing culture — they do not happen by accident.

How do you measure deployment frequency?

Deployment frequency is measured by counting how many times per day, week, or month your team successfully deploys to the production environment. The most reliable source is your CI/CD pipeline: tag every pipeline run that targets production and query the frequency over a 30-day rolling window. GitHub Actions environment deployments and GitLab deployment events surface this automatically if your pipeline is configured to report environment targets.

What is a good mean time to recover for engineering teams?

A good MTTR is under one hour for elite performers and under one day for high performers. Teams with MTTR above one week are typically missing foundational observability — they cannot detect incidents quickly — or lack practiced incident response processes that enable fast resolution. Improving MTTR requires both better alerting to detect faster and better runbooks and rollback capabilities to resolve faster. Measure MTTR over 90-day rolling windows to see trends more clearly than spot measurements allow.

How long does it take to improve DORA metrics?

Teams that focus on one DORA metric at a time typically see measurable movement within 30 to 90 days. Deployment frequency and lead time respond fastest to CI/CD and process changes — teams have gone from monthly to weekly deployments in six weeks by eliminating manual gates and enforcing small PRs. Change Failure Rate and MTTR take longer because they require cultural changes alongside technical ones. The Accelerate research shows that sustained improvement happens when metrics are reviewed regularly and tied to specific engineering initiatives, not treated as a one-time audit.

How Belsoft Helps Engineering Teams Improve DORA Performance

When Belsoft works with an engineering organization, establishing a DORA baseline is one of the first things we do — before recommending any process or architecture change. The data almost always reveals a specific bottleneck: a CI pipeline that takes 45 minutes, a change failure rate driven by one underspecified service, or a lead time blowout caused by a manual approval process nobody has questioned. We design and build the CI/CD infrastructure, observability stack, and deployment practices that move the specific metrics that matter for your team. See our cloud infrastructure service for the CI/CD and observability layer we build on every engagement.

For the startup CTO building engineering discipline early, investing in DORA metric tracking before you have a large team pays the highest dividends — you establish habits that scale rather than needing to reform entrenched ones. If you want to discuss what your team's current DORA baseline looks like and what a realistic improvement path is, book a call with Belsoft.

“You cannot improve what you do not measure — but measuring without acting is just expensive reporting.”