Teams that ship infrequently don't just move slower. They accumulate risk. Every day code sits undeployed is a day bugs compound, feedback gets delayed, and your delivery pipeline loses visibility. Deployment frequency measures how often your squad successfully releases code to production. It is one of the four DORA metrics and one of the clearest signals of how well your engineering system is actually functioning. This page covers the definition, how to measure it against published benchmarks, what low frequency typically signals, and how to act on the data.
Key takeaways
- Deployment frequency measures how often a squad successfully ships code to production. It matters because it is a direct proxy for delivery throughput, feedback loop speed, and release risk. Teams that deploy more often tend to ship smaller changes, which means lower blast radius when something goes wrong and faster iteration on what users actually need.
- Deployment frequency is calculated as the number of successful production deployments divided by the time period measured. For example, 20 deployments over 30 days equals a daily average of 0.67 deployments per day. According to the 2023 DORA State of DevOps Report, elite performers deploy on demand or multiple times per day, while low performers deploy fewer than once per month.
- The most common mistake teams make is confusing deployment frequency with deployment size. Shipping once a month is not inherently safer than shipping daily. In fact, large infrequent releases concentrate risk. If your frequency is low, the first question to ask is whether your batch sizes are too large, not whether your team is moving too fast.
- DevStats tracks deployment frequency automatically by connecting to your Git provider and CI/CD pipeline, with benchmarks against 1,000+ engineering teams. You can see your squad's deployment frequency alongside related signals like PR cycle time and throughput in under two minutes. Start a free trial to see your numbers.
Deployment frequency definition
Deployment frequency is the measure of how often an engineering team successfully deploys code to production. It counts only successful deployments, not attempts, and is typically expressed as deployments per day, week, or month depending on the team's release cadence.
The formula is straightforward: Deployment Frequency = Number of successful production deployments / Time period measured. Data sources include your CI/CD pipeline, deployment tooling (such as GitHub Actions, CircleCI, or ArgoCD), and your Git provider. Teams using DevStats can pull this data automatically through the deploy feature, which surfaces deployment activity without requiring manual log reviews.
From a business perspective, deployment frequency is a leading indicator of your team's ability to respond to market feedback, fix defects quickly, and deliver committed roadmap items on schedule. It is one of the four core DORA metrics alongside lead time for changes, change failure rate, and mean time to restore. If you want a single number that tells you how well your delivery system is functioning end to end, deployment frequency is a strong starting point.
Why deployment frequency matters for engineering teams
When squads don't track deployment frequency, they often don't realize how infrequently they're actually shipping until a stakeholder asks why a feature committed three sprints ago still isn't live. Invisible batch buildup is one of the most common causes of missed release dates, and it rarely shows up in sprint velocity reports. By the time the problem surfaces, it's already compounded into a delivery crisis rather than a manageable bottleneck.
For engineering leaders, deployment frequency connects directly to KPIs that matter to the business: on-time delivery, mean time to recover from incidents, and the ability to respond to competitive pressure with speed. Teams that deploy frequently tend to have shorter PR cycle times, tighter feedback loops, and more predictable sprint outcomes. Low deployment frequency is often a symptom of friction somewhere upstream, whether in code review, testing, or release approval processes, and measuring it is what makes that friction visible.
Deployment frequency sits at the core of the DORA framework and aligns with the Flow dimension of the SPACE framework. It measures the delivery process, not individual contributors. Measurement is the first step. What you do with the data is where your judgment as an engineering leader matters most.
How to measure deployment frequency
To calculate deployment frequency, count every successful deployment to your production environment over a defined time window, then divide by the number of days, weeks, or months in that window. "Successful" means the deployment completed without an immediate rollback. Partial deployments, feature flags, and canary releases should be counted consistently across periods so the metric stays comparable over time.
Data sources you'll need: your CI/CD pipeline logs (GitHub Actions, CircleCI, Jenkins, ArgoCD), your Git provider for merge and tag events, and optionally your incident tracking tool to distinguish successful from failed deployments. DevStats pulls this data automatically and surfaces it in the deploy dashboard, alongside benchmarks against 1,000+ engineering teams so you can contextualize your numbers without guessing.
The table below uses benchmarks from the 2023 DORA State of DevOps Report.
| Performance level | Deployment frequency benchmark | What it signals |
|---|---|---|
| Elite | On demand (multiple times per day) | Continuous delivery is fully operational. Batch sizes are small. Release risk is low. |
| High | Once per day to once per week | Healthy cadence. Some process friction may exist but delivery is consistent. |
| Medium | Once per week to once per month | Batch sizes are growing. Manual gates or review bottlenecks are likely slowing release. |
| Low | Fewer than once per month | High-risk releases. Significant process friction. Feedback loops are slow and delivery predictability is low. |
Deployment frequency in practice: a real example
A VP of Engineering at a 40-person SaaS company noticed that their squad was completing sprint work on time but features were still reaching customers weeks later than planned. After pulling three months of deployment data, she saw the squad was averaging fewer than two production deployments per month despite shipping code to staging frequently. The bottleneck wasn't velocity. It was a manual release approval process that required sign-off from two senior engineers who were already stretched across multiple squads.
She restructured the release process: automated the staging-to-production promotion for services with full test coverage, and moved release approval to a lightweight async review for lower-risk services. Within six weeks, deployment frequency moved from roughly 1.5 per month to 3 to 4 per week. She tracked the change using deployment data alongside throughput and sprint completion rates to confirm the process change was producing the intended result without increasing incident rates.
How to improve deployment frequency
- Reduce your batch size. The single most effective way to increase deployment frequency is to ship smaller changes more often. Break features into independently deployable increments. If your pull requests are regularly exceeding 400 lines of changed code, that's a signal that your squad is batching too much before review. Smaller PRs move through code review faster and are safer to deploy.
- Automate your release pipeline. Manual deployment steps are the most common bottleneck for squads stuck in the medium performance tier. Identify every human gate in your path to production and ask whether it can be replaced by an automated check. Start with test coverage gates and smoke tests. Manual approval should be reserved for changes that genuinely require human judgment.
- Shorten your PR cycle time. Deployment frequency is downstream of how fast code moves from open PR to merged. If reviews are taking more than 24 hours on average, deployments will queue up. Review your PR cycle time data to find where reviews are stalling, whether that's time to first review, time to approval, or time to merge after approval.
- Use feature flags to decouple deploy from release. Feature flags let your squad deploy code to production without exposing it to users. This separates the technical act of deploying from the business act of releasing, which removes a major psychological and process barrier to frequent deployment. It also lets you roll back a feature without a full deployment.
- Measure leading indicators, not just the outcome. Deployment frequency is the outcome metric. The leading indicators are PR cycle time, issue cycle time, and build success rate. DevStats surfaces all of these in a single view so you can see which upstream signal is constraining your deployment cadence before it shows up as a missed sprint.
Deployment frequency vs. release cadence
Deployment frequency and release cadence are often used interchangeably, but they measure different things. Deployment frequency counts how often code is successfully pushed to production. Release cadence describes how often new functionality is made available to end users. A team can deploy to production 20 times per week using feature flags while releasing new functionality to customers only once per sprint.
| Deployment frequency | Release cadence | |
|---|---|---|
| Measures | How often code reaches production | How often users receive new functionality |
| Starts when | A deployment is triggered | A feature is enabled for users |
| Ends when | Deployment completes successfully | Feature is live and available to the target audience |
| Best for | Diagnosing delivery pipeline health | Communicating product delivery to stakeholders |
Use deployment frequency to diagnose your engineering process. Use release cadence when communicating delivery commitments to product and business stakeholders. Tracking both gives you a complete picture of where code is in the system at any given time.