Deployment frequency benchmarks turn a raw cadence into a meaningful signal. Knowing you deploy once a week tells you your schedule. It doesn't tell you where you sit in the industry distribution, how far the gap to elite performance is, or what that gap costs in feedback latency and business outcomes.
This post covers the four DORA performance tiers and their deployment frequency thresholds, where teams across the industry landed in the 2024 State of DevOps Report, what separates elite performers from the rest in practice, and what the data shows for regulated sectors like banking and FinTech where governance overhead compounds the challenge.
What Deployment Frequency Measures
Deployment frequency is the number of times per period that a team successfully releases code to production. It is one of the four DORA (DevOps Research and Assessment) metrics, alongside lead time for changes, change failure rate, and failed deployment recovery time.
Unlike metrics that measure quality or recovery speed, deployment frequency is a direct measure of throughput: how often your team gets working software in front of users. Higher frequency signals healthy engineering fundamentals: small batch sizes, short feedback loops, and a delivery pipeline trusted enough to run often.
One measurement point worth noting: deployment frequency counts successful releases to production only. Build runs, staging deployments, and feature flag activations do not count. A deployment registers when code reaches production users.
For a full breakdown of how deployment frequency relates to the other three DORA metrics, see our guide to the four DORA metrics.
The Four DORA Performance Tiers
DORA classifies software delivery organisations into four performance tiers based on deployment frequency and the other three key metrics. The definitions originate from DORA's research program and the Accelerate book (Forsgren, Humble, and Kim, 2018):
One important caveat from DORA's documentation: these tiers are not fixed cutoffs. They are derived via cluster analysis on annual survey data, meaning the boundaries shift year to year as the sample evolves. Treat them as directional benchmarks, not precise pass/fail thresholds.
Where Teams Sat in 2024
The 2024 DORA State of DevOps Report, published by Google Cloud and the DORA research program, found the following distribution across performance tiers:
- Elite: approximately 19% of teams
- High: 22% of teams (down from 31% in 2023)
- Low: 25% of teams (up from 17% in 2023)
The year-over-year shift is the more important story. The high performance tier shrank from 31% to 22%, while the low tier grew from 17% to 25%. Elite remained stable. The industry is not improving on aggregate: the teams in the middle are moving down, not up.
The 2024 report also noted that for the first time, the medium performance cluster recorded a lower change failure rate than the high cluster. Both clusters reported failure recovery times of under one day. This is consistent with a decade of DORA's core finding: higher deployment frequency does not trade against stability. Teams that deploy more often fail less often and recover faster.
A note on the framework: the 2025 DORA research program retired the four-tier classification. The 2025 report moved to seven team archetypes based on the intersection of delivery performance and human factors such as burnout and organisational friction. The 2024 figures above are the last published in the four-tier format, which is why they remain the primary reference for tier-based deployment frequency benchmarking.
What Elite Teams Do Differently
The performance gap between elite and low performers is large enough to describe them as different categories of organisation. According to DORA research across multiple years of data:
- Elite performers deploy 182x more frequently than low performers
- Elite performers have 127x faster lead times for changes
- Elite performers have 8x lower change failure rates
- Elite performers recover from failures 2,293x faster
An organisation deploying on-demand multiple times a day and one deploying less than once a month are operating on completely different delivery models. The gap is not primarily a tooling gap. It is a practice gap.
Elite teams share a consistent set of practices: trunk-based development with no long-lived feature branches, automated tests that run on every commit, small batch sizes that limit the blast radius of any release, and a deployment pipeline fast and reliable enough that running it feels routine. The pipeline is the control. The deployment is not the event.
The business case is measurable. DORA research found that elite performers are 2x more likely to exceed profitability, productivity, and customer satisfaction targets. Separate analysis found 50% higher market capitalisation growth and 2.5x faster time to market in high-performing engineering organisations.
Ten-year finding: Every DORA State of DevOps Report since 2014 has confirmed the same result: throughput and stability are not a tradeoff. Teams that deploy more frequently have fewer failures and recover faster when failures do occur.
Industry Context: SaaS, Enterprise, and Regulated Sectors
Deployment frequency benchmarks are not uniform across all software organisations. Two structural factors shape what is achievable before any team-level practice differences come into play.
Delivery model. SaaS products deploy directly to cloud infrastructure, making on-demand releases straightforward. Mobile apps are constrained by App Store and Google Play review cycles, which add days to the process. On-premise software must be packaged, distributed, and installed by customers, making high-frequency releases impractical at scale. DORA's benchmarks skew toward cloud-native delivery models.
Governance and approval overhead. This is where the data becomes particularly relevant for teams in financial services, healthcare, and other regulated industries. DORA research found:
- Organisations with formal external approval processes are 2.6x more likely to be low performers across all four DORA metrics
- DORA found no evidence that formal change advisory board (CAB) approval processes reduce change failure rates
- Manual change management was negatively correlated with deployment frequency, lead time, and restore time
The UK Financial Conduct Authority conducted its own analysis of production change data across financial institutions and found that the majority of firms were at very low performance levels for deployment frequency on core systems. That is consistent with DORA's finding on approval overhead.
However, DORA is explicit on this point: industry is not a barrier to elite performance. Elite performers exist in regulated sectors. The distinction is not whether you have controls: it is whether those controls are automated and embedded in the pipeline, or manual and applied as external gates. Banks and FinTech organisations that implement governance-as-code consistently outperform those relying on manual CAB approvals, because automated controls enforce policy without adding lead time. For more on how this works in banking, see our post on DORA compliance for banking DevOps.
Per-Developer Benchmarks
DORA's tiers measure deployment frequency at the team or organisation level. The 2026 LinearB Software Engineering Benchmarks Report takes a different approach: deployments per developer per week. This normalises for team size, making it useful for comparing teams of different scales.
The report covered data from 4,800 development teams and over 8.1 million pull requests and branches:
Across all cohort years, LinearB's data consistently shows an enterprise throughput penalty. Larger codebases, more complex approval chains, and more infrastructure surface area compound into a delivery gap that is difficult to close without structural changes to how work is batched and reviewed.
How to Measure Deployment Frequency
Most CI/CD platforms surface deployment frequency natively. GitHub Actions, GitLab CI, CircleCI, Buildkite, and Harness all track production deployment events. The key is agreeing on what counts before you start benchmarking:
- Production releases only: staging or pre-production deployments do not count
- Successful deployments only: failed pipeline runs are not deployments
- Per service, not per repo: in a microservices architecture, measure at the service level to avoid high-frequency services masking low-frequency ones in your aggregate
- Feature flags are not deployments: code shipped to production behind a flag is deployed, but the flag activation is a release event, not a deployment
For teams that want ongoing visibility into their DORA tier rather than a one-time snapshot, engineering intelligence platforms aggregate deployment events across services and give you a continuous benchmark. The Scrums.com platform tracks deployment frequency and the other three DORA metrics at the team level, making tier assessment a live data point rather than an annual survey answer.
Frequently Asked Questions
What is the DORA elite tier for deployment frequency?
DORA elite performers deploy on-demand, typically multiple times per day. There is no fixed numerical threshold because the tiers are derived via cluster analysis on annual survey data and shift year to year. In practice, elite teams deploy small batches of code to production whenever they have working software ready, often dozens of times daily across multiple services.
What percentage of teams are DORA elite performers?
The 2024 DORA State of DevOps Report found approximately 19% of surveyed teams qualified as elite performers. This was the last report in the four-tier format: the 2025 DORA research program retired the Elite/High/Medium/Low model in favour of seven team archetypes. The 2024 figures remain the industry reference for tier-based benchmarking. The notable shift: the high tier shrank from 31% to 22% between 2023 and 2024, while the low tier grew from 17% to 25%.
How does deployment frequency differ in FinTech and banking?
Regulated industries typically show lower deployment frequency due to governance overhead. DORA research found organisations with formal external approval processes are 2.6x more likely to be low performers. The UK FCA's analysis found the majority of financial firms at very low performance levels for core system deployment frequency. That said, DORA is clear that industry is not a barrier to elite performance. Banks that automate compliance controls rather than relying on manual approval gates consistently achieve higher performance tiers.
What counts as a deployment for measurement purposes?
A deployment counts when code is successfully released to production and reaches production users. Build runs, staging deployments, and feature flag activations do not count. For microservices architectures, measure deployment frequency at the service level rather than aggregating across a repository, to avoid high-frequency services masking low-frequency ones in the overall metric.
What is a good deployment frequency for a small engineering team?
LinearB's benchmarks define strong performance as 0.09 to 0.2 deployments per developer per week, with elite at above 0.2. For a five-person team, strong performance is roughly one deployment every two to three days. Daily deployments put a small team in the elite tier. For SaaS teams these levels are achievable with solid CI/CD automation. For mobile or on-premise teams, the delivery model limits frequency regardless of engineering maturity.
The benchmarks above show a consistent picture across ten years of DORA research: elite teams deploy on-demand, have lower change failure rates than teams deploying infrequently, and deliver measurably better business outcomes. The risk is not in deploying often. The risk is in large batches, manual gates, and infrequent releases that make each deployment a high-stakes event.
Want to track your team's deployment frequency against DORA benchmarks continuously? The Scrums.com engineering intelligence platform surfaces deployment frequency, lead time, change failure rate, and recovery time in real time. Or start with our full guide to the four DORA metrics to see how deployment frequency fits the broader framework.
