DORA Metrics: The question that engineering leadership has always struggled to answer credibly is whether the development team is getting better. Velocity in story points is gameable. The number of features shipped does not account for quality. Bug counts tell you something about stability but nothing about delivery speed.
The metrics that engineering organizations have historically used to report their own performance have been either too easy to manipulate or too disconnected from the outcomes that matter to the business to serve as genuine accountability mechanisms.
The genius of the DORA Four Keys is the split. Deployment frequency and lead time measure throughput, how quickly value moves from a developer’s keyboard to a user’s screen. Change failure rate and recovery time measure stability: what happens when something breaks. Optimize throughput alone, and you ship chaos. Optimize stability alone, and you ship nothing.
DORA’s research showed elite teams refuse the trade-off: they are fast and safe at the same time. The framework is not a methodology for improving software delivery. It is a measurement framework that makes the quality of software delivery visible in a way that resists the most common forms of metric manipulation, because the four metrics cross-validate each other.
Deployment Frequency: The Speed Signal That Rewards Small Changes
Deployment frequency measures how often your team successfully deploys code to production. Elite performance is multiple times per day. High performance is once a week to once a month. Medium performance is once a month to once every six months. Low performance is less than once every six months. Deploying rarely is usually a symptom of overly manual processes or bloated release cycles.
The mechanism by which deployment frequency predicts delivery quality is not immediately intuitive. A team that deploys once a month typically deploys a large batch of changes accumulated across four weeks. If that deployment fails, diagnosing the root cause requires searching through four weeks of changes, a debugging exercise that is proportionally more difficult than the corresponding exercise for a team that deployed six hours ago and has twelve changes to examine. Smaller deployments are safer, because the blast radius of any individual change is smaller and the diagnostic surface when something goes wrong is narrower.
Feature flags are the most powerful tool for improving deployment frequency without increasing risk; code can be deployed to production in a dormant state and activated for users only when ready, removing the need to wait for everything to be complete before a deployment is made. Trunk-based development, where short-lived branches are merged frequently, eliminates the integration conflicts that accumulate in long-lived branches and keeps the codebase deployable at all times.
The gaming trap that deployment frequency introduces is visible in the Deployment Rework Rate. A team that splits work artificially into trivial commits to inflate their deployment frequency number will show an elevated rework rate, because the artificial splits produce more reverts, more patches, and more re-releases than genuine small changes do. The two metrics together distinguish real delivery improvement from frequency inflation.
Lead Time for Changes: The Bottleneck Finder
Lead time for changes measures the time between the first commit of a change and its successful deployment to production. Elite performance is under one hour. High performance is under one day. Medium performance is one week to one month. Low performance is one to six months.
The value of lead time as a diagnostic metric is that it reveals where the delay lives. A team whose average lead time is three weeks has three weeks of work somewhere between “code written” and “code live“, and the lead time breakdown identifies whether that time is spent in code review queues, in CI pipeline execution, in manual deployment approval processes, in release management gates, or in environment provisioning. Each delay location has a different intervention.
Code review SLA violations are one of the biggest contributors to long lead times; unreviewed code sitting in a pull request queue accumulates waiting time that is invisible in most reporting dashboards but represents the largest controllable component of lead time for most teams. Setting explicit SLAs on code review (a maximum response time for first review, a maximum time to merge after all comments are addressed) is the intervention that most consistently reduces lead time without requiring any pipeline infrastructure change.
Leading organizations report average lead times as low as 15 minutes in 2026, achieved through automated testing that runs in parallel, infrastructure as code that eliminates environment provisioning delays, and cloud-native deployment strategies that make production deployment a pipeline step. Fifteen minutes from commit to production is achievable for small services with mature pipeline infrastructure, and it is the number that makes the question “should we deploy this today or wait for the next release window?” disappear entirely from the vocabulary, because the release window is whenever the pipeline completes.
Change Failure Rate: The Quality Signal That Prevents Gaming the Others
Change failure rate represents the percentage of failed deployments that result in a degraded service requiring remediation. It is an incident management metric used to measure stability. Top-performing teams maintain a change failure rate between 0% and 15%. A high change failure rate indicates possible issues in review processes, integration practices, or deployment procedures.
The critical definitional nuance in change failure rate is what counts as a failure. Not every bug that appears after a deployment counts; only failures that require immediate rollback, hotfix, or patch. A performance degradation that is noticed and logged but not addressed until the next sprint is not a change failure in the DORA sense. A service outage that triggers an emergency deployment is.
Change failure rate is the metric that cross-validates deployment frequency. A team that dramatically increases deployment frequency without addressing underlying quality problems will see its change failure rate rise, and the rising failure rate makes the frequency improvement meaningless, because more deployments are producing more incidents. The four keys form a balanced scorecard where improving one without wrecking another is the actual signal of an elite team.
Under-reporting failures to keep the change failure rate low is the most insidious gaming pattern; teams categorise incidents as pre-existing issues. The correct definition is strict: if the deployment caused the condition that triggered the incident, it counts. If the incident would have occurred regardless of the deployment, it does not.
The improvement interventions that most reliably reduce change failure rate are expanded automated test coverage (particularly integration tests that verify cross-service behavior), improved canary and progressive delivery practices that limit the blast radius of any individual deployment, and post-incident reviews that identify which test coverage gaps would have caught the failure before it reached production.
MTTR: The Recovery Signal That Reflects Operational Maturity
Mean Time to Restore measures how quickly the team recovers service after a production incident. Elite performance is under one hour. High performance is under one day. Medium performance is one day to one week. Low performance is more than one week.
MTTR is the metric that most directly reflects operational maturity. A team can improve its deployment frequency through CI/CD automation, its lead time through pipeline optimisation, and its change failure rate through test coverage – all development-side interventions. MTTR improvement requires operations-side investment: observability infrastructure that detects incidents faster, runbooks and playbooks that structure the response, escalation paths that get the right people paged immediately, and rollback mechanisms that can restore a previous state in minutes.
To reduce MTTR, teams should adopt incident management automation, chaos engineering, and observability-driven operations. Prometheus and Grafana provide real-time visibility into system health and enable proactive issue detection; the goal is detecting the incident before users report it, which is the difference between a two-hour MTTR and a twenty-minute one.
The gaming trap for MTTR is premature incident closure. Closing incidents before service is fully restored improves the recorded recovery time without improving the actual user experience; the metric shows recovery in thirty minutes while users continue to experience degraded performance for another two hours. The correct definition is service fully restored to its pre-incident baseline, not the moment the on-call engineer believes the problem is resolved.
Feature flags are the operationally simple MTTR improvement that most teams underutilize. Feature flags map directly to MTTR, an instant disable of the flag that controls a failing feature restores service in seconds without a deployment or a rollback, making the recovery time the time to identify the feature. For teams with high deployment frequency and feature-flag-controlled releases, MTTR for any flag-controlled feature is operationally bounded by the time to detect and flip the flag, a ceiling that is achievable in minutes.
Building the Dashboard: Measurement Before Improvement
Start by establishing a baseline — gather data on current deployment frequency, lead times, change failure rates, and time to restore service. This baseline is the starting point for improvement, not a benchmark to be compared against industry averages before context is understood.
The data sources that DORA metrics require are available in most existing toolchains without new infrastructure investment. Deployment frequency and lead time come from CI/CD pipeline logs: the timestamp of the commit that initiated the pipeline and the timestamp of the successful production deployment. Change failure rate requires an incident classification system that links incidents to the deployment that caused them, typically through PagerDuty or similar incident management tools that can be tagged with the deployment ID. MTTR comes from incident start and end timestamps in the same system.
Automation is essential for reliable DORA metric collection; manually assembled metrics produce inconsistent definitions and create the conditions for inadvertent gaming. GitHub Actions, GitLab CI, and Jenkins all expose the pipeline data that deployment frequency and lead time require. The investment that pays off most is consistent incident tagging at the source: an incident tagged with its causing deployment ID at creation time is the data foundation that makes change failure rate reliable without manual attribution after the fact.
The critical practice that protects the metrics from becoming performance management tools: DORA metrics should never be tied to individual performance reviews or compensation. The moment they become individual performance metrics, the gaming patterns that undermine their validity appear immediately and consistently across every team that has tried it. They are team metrics, used by the team to understand its own delivery system.
The Fifth Metric: Deployment Rework Rate
The Deployment Rework Rate, added to the DORA framework in 2024, measures the proportion of the deployment pipeline consumed by fixing previously completed work (reverts, hotfixes, and re-releases of work) that was considered done. A high rework rate signals instability in the delivery process and directly impacts both lead time and deployment frequency by consuming pipeline capacity with corrective work.
Rework rate is the anti-gaming metric. A team that games deployment frequency by splitting work into trivial changes will show elevated rework because trivial changes that do not represent complete units of value produce more reverts. A team that games MTTR by closing incidents prematurely will show elevated rework because the same issue resurfaces. The rework rate makes the cross-validation function of the Four Keys explicit and adds a fifth signal that is difficult to game without simultaneously degrading the metrics it is designed to protect.
What to Watch Next
The 2026 state of DORA metrics reflects two structural shifts that are changing how teams interpret their numbers. The first is AI-assisted coding, where tools like GitHub Copilot have increased deployment frequency for some teams without proportional quality improvement, producing elevated change failure rates that reflect the speed increase without the corresponding test coverage maturation. The teams managing this transition well are the ones that invested in automated test generation alongside AI code generation, keeping the stability metrics in balance as throughput increased.
The second shift is the expansion of DORA measurement into AI and ML delivery pipelines: model deployment frequency, model change failure rate, and model recovery time are becoming the DORA equivalents for teams whose most consequential deployments are model updates. The framework translates directly; the data sources and tooling for collection are still maturing.
For DevOps and engineering teams beginning their DORA practice, the sequencing that produces the most reliable results is: establish baselines before setting targets, automate data collection before reporting results, read all four metrics as a set before acting on any individual one, and never attach individual performance consequences to team-level metrics. The teams that follow this sequence build measurement systems that improve delivery. The teams that skip it build dashboards that improve numbers.
(Source)