Deployment Frequency
DORA Metric Explained
How often code reaches production — and what that number tells you.
Deployment frequency is one of the four key metrics from the DORA research program. It measures how often your team ships code to production. Low frequency is usually a symptom, not a cause — the real problems are batch size, test confidence, and process friction.
Definition
What deployment frequency measures and why it matters
Deployment frequency is a count: how many times per time period does a team successfully deploy a code change to production? That count is a proxy for two things: batch size and risk per deploy.
Teams that deploy once per month are shipping large batches — weeks of accumulated changes in a single deployment. Large batches are harder to test, harder to review, and harder to diagnose when they fail. A failure in a 200-commit deployment is a debugging problem. A failure in a 5-commit deployment is usually solvable in minutes.
Teams that deploy multiple times per day have inverted that risk profile. Each deployment is small — typically a single feature or bugfix — which means the surface area of what can go wrong is small, and automated rollback handles the failure cases quickly.
The DORA research program has measured this relationship across thousands of organizations over more than a decade. The consistent finding: elite performers deploy frequently AND have better reliability outcomes. High deployment frequency and high stability are not in tension — they move together once a team has the platform capabilities to support both.
DORA benchmarks
The four performance tiers
Source: DORA State of DevOps research program, dora.dev
What limits deployment frequency
Four common constraints
Each of these is a platform or process problem, not a people problem.
Fear of breaking production
When a deployment might cause an outage and rollback is manual and slow, teams batch changes to reduce deployment frequency. The fear is rational — each deploy is high-risk. The fix is reliability work: better testing, automated rollback, feature flags.
Long test suites
If running the full test suite takes two hours, the CI/CD pipeline cannot support multiple daily deployments without dedicated fast-feedback stages. Platform teams address this with parallel test execution, test impact analysis, and tiered pipelines.
Manual approval gates
A change approval process that requires a human approval before production — with no automated checks — is a hard cap on deployment frequency. The approval queue becomes the bottleneck. Risk-based automation (auto-approve changes that pass all gates; require human review only for exceptions) removes the ceiling.
Missing feature flags
Without feature flags, every deployment is also a release. Teams that cannot decouple deploy from release reduce deployments because every deploy is a user-visible event. Feature flags allow code to ship to production before it is visible to users, removing that constraint.
Platform team levers
How platform teams improve deployment frequency
Standardized CI/CD golden path. A CI/CD pipeline that runs fast, reliable tests on every commit and deploys automatically when they pass removes the activation energy of each individual deployment. Teams stop thinking of deployment as an event and start treating it as a consequence of merging code.
Deployment previews and environments on demand. Self-service preview environments for every pull request allow teams to test changes before merging, which increases confidence in each deployment and reduces the need for large staging runs before each production release.
Automated testing at the right layers. Comprehensive automated tests — unit, integration, and a focused set of end-to-end tests — are the confidence layer that makes frequent deployment safe. Platform teams set the testing standards and infrastructure; application teams implement them.
Feature flags. Feature flags decouple deployment from release. Code ships to production; the flag controls when users see it. This allows teams to deploy constantly without every deploy being a user-visible release event. See the feature flags glossary entry for the full treatment.
Platform Foundation engagement
The Platform Foundation engagement builds the CI/CD golden paths, deployment automation, and feature flag infrastructure that remove the ceilings on deployment frequency.
See the Platform Foundation engagementCommon questions
Deployment frequency: direct answers
What is a good deployment frequency?
The DORA research (dora.dev) categorizes organizations into four performance bands. Elite: multiple deployments per day. High: between once per day and once per week. Medium: between once per week and once per month. Low: less than once per month. "Good" is context-dependent — a team moving from monthly to weekly deployments has made a meaningful improvement even if it is not yet at the elite tier. The trend matters as much as the absolute number.
How does deployment frequency relate to stability?
The DORA research consistently finds that elite performers deploy frequently AND have low change failure rates. The intuitive concern — that deploying more often means more risk — is empirically false at the elite tier. High-frequency deployments are typically smaller in scope, which makes them individually less risky and easier to roll back when something goes wrong.
Can you deploy too often?
In theory, yes — deploying broken code multiple times per day is worse than deploying working code once per week. In practice, teams that deploy frequently tend to have the testing and observability infrastructure required to do so safely. The constraint is quality gates, not frequency.
Know your DORA baseline
The Foundations Assessment measures your current DORA metrics and shows you where the ceilings are.
Four to six weeks. DORA baseline. Maturity radar. 90-day roadmap.