Most engineering leaders can feel when their delivery pipeline is slowing down, but they can't pinpoint where. Accelerate metrics give you a precise, research-backed framework for measuring software delivery performance across four dimensions. Originally defined in the book Accelerate by Nicole Forsgren, Jez Humble, and Gene Kim, these metrics are the foundation of what the industry now calls DORA metrics. This page covers the definition, how to measure each metric, published benchmarks, a real-world example, and how DevStats surfaces the data so you can act on it.
- Accelerate metrics are a set of four engineering performance indicators derived from six years of research by the DORA team. They matter because they are the only software delivery metrics empirically linked to organizational performance and business outcomes, not just engineering velocity.
- The four metrics are deployment frequency (how often you deploy to production), lead time for changes (commit to production time), change failure rate (percentage of deployments causing incidents), and mean time to restore (how fast you recover). Elite performers deploy multiple times per day with a lead time under one hour, per the 2023 DORA State of DevOps Report.
- The most common mistake teams make is optimizing one metric in isolation. Squads that push deployment frequency up without investing in testing infrastructure typically watch their change failure rate climb in parallel, which erases the gains.
- DevStats tracks accelerate metrics automatically by connecting to your Git provider, CI/CD pipeline, and incident tool, with benchmarks against 1,000+ engineering teams. Start a free trial to see your numbers in under two minutes.
Accelerate metrics definition
Accelerate metrics are four software delivery performance indicators used to measure how quickly and reliably an engineering team ships value to production. They are deployment frequency, lead time for changes, change failure rate, and mean time to restore (MTTR). Teams use them to benchmark delivery health against industry data rather than internal gut feel.
Each metric draws from a different data source. Deployment frequency comes from your CI/CD pipeline or deploy logs. Lead time for changes measures the elapsed time from first commit to production deployment. Change failure rate equals the number of deployments causing a failure divided by total deployments, expressed as a percentage. MTTR measures the time from incident detection to full service restoration. Together, the four metrics reflect both throughput and stability, the two dimensions that Accelerate research shows are not in tension for high-performing teams. When your squad improves all four simultaneously, it is a reliable signal of a healthy delivery system, and that signal translates directly into faster feature delivery and lower operational cost for the business. You can see how DevStats surfaces all four through its DORA metrics feature, which maps each indicator to your connected data sources automatically.
Why accelerate metrics matter for engineering teams
Without a shared measurement framework, engineering leaders default to proxy metrics: story points, lines of code, or ticket counts. None of those tell you whether your squad is actually delivering value faster or more safely. Teams that skip accelerate metrics often find out about delivery problems through missed sprint commitments, escalating incident rates, or frustrated stakeholders, not through proactive data.
Accelerate metrics connect directly to the KPIs engineering leaders are held to. Deployment frequency and lead time for changes determine how quickly product decisions reach users. Change failure rate and MTTR determine how much of your squad's capacity gets consumed by unplanned work. When those four numbers are visible, you can have a fact-based conversation with your CTO or product leadership about where investment is needed, whether that's in test coverage, deployment automation, or on-call processes. The metrics align with the DORA research framework and complement the SPACE framework's emphasis on measuring systems rather than individuals.
Measurement is the starting point. The data tells you where the friction is. The engineering leader decides what to do about it.
How to measure accelerate metrics
Each of the four accelerate metrics requires a different data source. Deployment frequency pulls from your CI/CD pipeline, deploy scripts, or release management tool. Lead time for changes requires Git commit timestamps matched against deployment timestamps. Change failure rate requires incident or alert data cross-referenced with deployment events. MTTR requires incident management data with detection and resolution timestamps. Most squads need to connect at least three systems to get a complete picture: a Git provider, a CI/CD tool, and an incident management platform.
The benchmarks below are drawn from the 2023 DORA State of DevOps Report. Note that benchmarks vary by team size, codebase maturity, and release model. Use them as directional reference points, not hard targets. DevStats's benchmarks feature lets you compare your numbers against teams of similar size and stage.
| Performance level | Deployment frequency | Lead time for changes | Change failure rate | MTTR |
|---|---|---|---|---|
| Elite | Multiple deploys per day | Less than one hour | 0–5% | Less than one hour |
| High | Once per day to once per week | One day to one week | 5–10% | Less than one day |
| Medium | Once per week to once per month | One week to one month | 10–15% | One day to one week |
| Low | Less than once per month | More than one month | More than 15% | More than one week |
Source: 2023 DORA State of DevOps Report. Change failure rate and MTTR thresholds are approximate ranges consistent with published DORA research.
Accelerate metrics in practice: a real example
A VP of Engineering at a 40-person SaaS company noticed that the squad was shipping features on schedule during sprints but still generating frequent customer-reported incidents. She pulled her accelerate metrics data and found deployment frequency was healthy at multiple times per week, but change failure rate sat at 18%, well into the low-performer band. Lead time for changes was also longer than expected at around three weeks, which pointed to a bottleneck somewhere between code review and production. The data gave her a specific question to investigate rather than a vague sense that something was wrong.
She ran a retro focused on the deployment pipeline and discovered that the squad had no automated integration tests. Players were merging PRs that passed unit tests but broke integration points downstream. She prioritized two sprints of test infrastructure work and assigned ownership of the CI pipeline to a senior player. Six weeks later, change failure rate dropped to 8% and lead time shortened as players gained confidence in the pipeline. The deploy tracking data made the before-and-after comparison visible to the whole team.
How to improve accelerate metrics
- Reduce batch size to improve deployment frequency and lead time. Large PRs are the most common cause of long lead times. Set a squad norm for PR size, something under 400 lines of changed code is a reasonable starting point, and watch PR cycle time as a leading indicator. Smaller batches move through review faster and fail in more contained ways.
- Invest in automated test coverage before increasing deploy cadence. Pushing deployment frequency without test infrastructure reliably increases change failure rate. Audit your CI pipeline for coverage gaps before committing to a higher deploy target. Use your change failure rate trend as the guardrail metric.
- Build a defined incident response runbook to reduce MTTR. MTTR is rarely a technical problem alone. Most recovery delays come from unclear ownership and manual escalation steps. Document a step-by-step runbook for your top five incident types and assign a rotation. Measure time-to-acknowledge separately from time-to-resolve to find where the delay actually lives.
- Review throughput and deployment data together. A squad that ships a high volume of work but deploys infrequently is accumulating risk in a large release batch. Align your sprint cadence with your deploy cadence so that work ships continuously rather than in a single end-of-sprint push.
- Use code review data to surface bottlenecks in lead time. Long review queues are a top driver of extended lead times. Review your code review data to identify where PRs sit idle and whether review load is distributed unevenly across the squad.
Accelerate metrics vs. DORA metrics
Accelerate metrics and DORA metrics refer to the same four indicators. The term "accelerate metrics" comes from the book Accelerate, while "DORA metrics" refers to the same framework as maintained and published by Google's DevOps Research and Assessment team. The distinction matters only in conversation: if someone says "DORA metrics," they mean the same deployment frequency, lead time for changes, change failure rate, and MTTR framework.
| Accelerate metrics | DORA metrics | |
|---|---|---|
| Origin | Book: Accelerate (Forsgren, Humble, Kim) | Google DORA research program |
| Metrics included | Deployment frequency, lead time, CFR, MTTR | Same four, plus reliability in some versions |
| Best for | Framing the original research context | Referencing current annual benchmarks |
| Updated annually | No (book is static) | Yes, via State of DevOps Report |
Use "DORA metrics" when referencing current benchmarks from the annual report, and "accelerate metrics" when citing the original research framework or the book.