DevOps Accelerate metrics are four specific measures, Deployment Frequency, Lead Time for Changes, Mean Time to Recovery, and Change Failure Rate, drawn from the research behind Accelerate by Dr. Nicole Forsgren, Jez Humble, and Gene Kim. Together they give engineering managers a signal about delivery speed and system stability that commit counts or story points simply cannot provide. Traditional output metrics put teams in competition with one another; the Accelerate four orient everyone toward a shared outcome.
Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations, written by Dr. Nicole Forsgren, Jez Humble, and Gene Kim, studies the productivity models and strategies of companies that build software. Its central claim is that software delivery performance and organizational performance are directly linked, not two separate concerns that happen to sit in the same building.
The research spanned profit and non-profit organizations, digitally native companies and those mid-way through a digital transformation, across industries including manufacturing, finance, and agriculture. It was first published as peer-reviewed papers in academic journals before the book gathered the findings into one narrative. As Accelerate argues, the right practices can take a change from “committed to mainline” to “running in production” in hours rather than months.
The authors adapted the four key metrics from lean manufacturing principles. Lead Time and Deployment Frequency, the first two, are tempo metrics: their job is measuring speed and throughput. Mean Time to Recovery and Change Failure Rate are reliability metrics, and together the four create a balanced approach where speed and quality are read as one picture rather than two competing priorities.
Deployment Frequency and Lead Time for Changes. How often you ship, and how long a change takes to get there.
Mean Time to Recovery and Change Failure Rate. How fast you recover, and how often a change breaks something.
This was the first widely cited research to make the case that sound engineering practice can pursue speed and stability at the same time, rather than treating them as a trade-off you have to pick a side of. The Accelerate four, also known as DORA metrics since the same authors founded the DevOps Research and Assessment program, work best when read together. Waydev’s DORA Metrics Dashboard gives you exactly that combined view of your team’s delivery performance.
No industry novelty gets received with universal enthusiasm, and the Accelerate metrics are no exception. Measuring software delivery performance has long been considered close to impossible, and plenty of engineering leaders still treat it that way. Many relate better to output KPIs like lines of code, commit counts, or story points, because those numbers feel concrete. The problem is that none of them indicate actual throughput or the quality of what got delivered.
Because the underlying research spanned such a wide range of company types, Accelerate supports the case that these four metrics apply regardless of size, structure, or industry. The authors are explicit that success depends less on a company’s specifics and more on leadership creating the environment where teams can understand and adopt the model, and guiding them through that adoption rather than mandating it from a slide deck.
When different individuals or teams measure different things, they end up competing rather than collaborating, and that competition works against the project. The authors encourage engineering managers to focus on team-level outcomes instead of individual or departmental output, so people work toward a shared goal and prioritize quality and performance over sheer quantity. Waydev’s Team Insights reflects that same team-level lens rather than pitting contributors against each other on a leaderboard.
“How often does the organization deploy into production?”
In classical lean manufacturing, this metric focuses on batch size: smaller batches delivered more often increase performance. Software has no physical batch, so the authors measured release frequency instead, on the premise that a CI/CD pipeline handling fewer changes per release, tested more often, performs better.
Deployment Frequency reads more like an Agile metric than a DevOps one. It fosters innovation and hypothesis testing, so companies ship the features that actually benefit users rather than betting everything on one large release.
“How long does it take for a commit to be running in production?”
This metric focuses on technical capability, measuring the time spent testing, deploying, and delivering code for a specific feature. The authors’ underlying premise: code only creates value once it’s in production. Before that, it’s inventory, work sitting on a shelf with no return yet.
Organizations with strong technical foundations, well-designed systems, and mature integration and delivery pipelines are the ones that consistently improve this number.
“How long does it take a company to recover from a failure in production?”
The premise here is blunt: companies cannot avoid failures. Capacity errors, security incidents, expired certificates, DNS issues, these are normal consequences of running an active, constantly changing system. Some downtime, partial or total, is inevitable given enough time.
The real question isn’t whether something breaks. It’s how fast the team restores full operation once it does. Shorter recovery time means higher team performance and better end-user experience through the incident.
“How often do a company’s deployments generate failures in production?”
CFR is a valuable metric because it stops a team from optimizing throughput at the expense of quality, the same tension it addresses in lean manufacturing. In software, it measures whether releases and new features generate issues or degrade existing performance.
A high CFR means changes are disrupting the end user’s experience and pulling the team into unplanned work instead of the roadmap they committed to.
For years, DORA’s annual State of DevOps research sorted teams into four tiers, Elite, High, Medium, and Low, based on where they landed across the four metrics. That tiered model is useful context, but it’s worth knowing it’s now historical framing rather than DORA’s current approach.
| Tier | Deployment frequency | Lead time | Time to recover | Change failure rate |
|---|---|---|---|---|
| Elite | On demand, multiple times a day | Under one hour to under one day | Under one hour | 0 to 15 percent |
| High | Between once a day and once a week | One day to one week | Under one day | Roughly 16 to 30 percent |
| Medium | Between once a week and once a month | One week to one month | One day to one week | Roughly 16 to 30 percent |
| Low | Between once a month and once every six months | One to six months | One week to one month | 46 to 60 percent |
Scroll the table sideways on a small screen.
The 2025 DORA report retired the four-tier ranking in favor of seven team profiles that weigh delivery performance alongside human factors like burnout and organizational friction.2 The metric definitions haven’t changed. The idea that every team should be climbing toward one leaderboard position has.
The practical takeaway: use the tiers above as a sanity check against your own trend, not a target to chase for its own sake. DORA’s own research also found that AI adoption is now reshaping this picture, with higher AI usage correlating with increases in both delivery throughput and delivery instability at the same time, which is exactly the kind of nuance a single tier ranking used to flatten away.2
Once you’ve decided the four Accelerate metrics are worth tracking, the next step is actually measuring them, and this is where most engineering managers hit friction. Many still validate these numbers by hand, which means significant time spent gathering and reconciling data instead of acting on it.
This in-house approach requires constant manual input, which eats an engineering manager’s time and turns tracking into a task that keeps getting postponed. An automated solution removes that friction entirely.
Analyzing deployments individually across separate CI/CD tools and hand-building reports from the results isn’t a realistic workflow for engineering executives with a full agenda and a wide range of responsibilities. Waydev automatically pulls data from your CI/CD pipelines and aggregates your team’s DORA metrics, so the information you need sits in your dashboard a few clicks away rather than in a spreadsheet someone has to rebuild every sprint.
Inside your DORA metrics dashboard, you get a clear view of your team’s delivery performance without anyone manually correlating timestamps. Since the Accelerate research was published, the surrounding measurement landscape has expanded too: Waydev’s WAY Framework reads DORA alongside SPACE, Core 4, and AI adoption data from the same commit-level source, so the four metrics from this research sit next to the newer questions AI-assisted development has raised.
Yes. “Accelerate” refers to the book that introduced the four metrics; DORA, the DevOps Research and Assessment program, was founded by the same authors and continues the research. The terms are used interchangeably because they describe the same four measures.
Deployment Frequency and Lead Time for Changes are tempo metrics, measuring speed and throughput. Mean Time to Recovery and Change Failure Rate are reliability metrics, measuring stability. Read all four together for an accurate picture; any one in isolation can mislead.
They’re useful as a rough sanity check, but DORA’s own 2025 research moved past that single-ladder model toward seven team profiles that account for human and cultural factors alongside the raw numbers.2 Chasing a tier label for its own sake was already a known failure mode before that shift.
Yes, with scripts that read commit timestamps and manual logs for deploy counts and failure counts. It works, but it consumes real engineering-manager time every week and is the kind of task that quietly stops happening once things get busy, which is usually the moment you need the data most.
Connect your CI/CD pipeline and Waydev aggregates Deployment Frequency, Lead Time, MTTR, and Change Failure Rate automatically, no scripts, no manual logs.
Schedule a DemoWe’ll show you how to put Accelerate metrics to work for your team.
Benchmark figures in the historical tier table vary slightly by source and report year; use them directionally. Last verified September 2026.
Ready to unlock your SDLC productivity?
