Deployment frequency, defined
Updated
Deployment frequency measures how often an engineering team successfully releases code to production (or to end users). It is one of the four DORA metrics and is used as a proxy for delivery throughput: teams that deploy in small, frequent increments tend to ship lower-risk changes.
On its own, deployment frequency is easy to game and easy to misread — a high count can hide large, risky batches, and a low count can reflect deliberate release cadence rather than slow delivery. It is designed to be read as a pair with lead time for changes (the other throughput metric) and balanced against the two stability metrics, change failure rate and time to restore service.
What deployment frequency measures
Deployment frequency counts how often changes reach production over a period — per day, per week, or per month. It is a throughput signal: it describes the pace at which work leaves the pipeline and becomes available to users, not the quality of that work or the effort behind it.
The metric became widely used through the DORA (DevOps Research and Assessment) program and the book Accelerate by Nicole Forsgren, Jez Humble, and Gene Kim (2018), which identified four measures — deployment frequency, lead time for changes, change failure rate, and time to restore service — that together correlate with software delivery performance. Deployment frequency and lead time capture speed; change failure rate and restore time capture stability. The design intent is that the two dimensions are read together, so that speed is never optimized at the expense of reliability.
- Throughput proxy: how often value is delivered, not how much or how good.
- Favors small batches: frequent, incremental releases are generally lower-risk than large, infrequent ones.
- Paired metric: designed to be interpreted with lead time for changes, not alone.
- Balanced by stability: high frequency is only healthy if change failure rate and restore time stay low.
How it is counted (and where definitions drift)
The honest answer is that the number depends on how you define a deployment. Teams that deploy several services independently, use feature flags to decouple deploy from release, or run continuous deployment will count very differently from teams that batch a release train weekly. Before comparing two teams, confirm they define a deployment the same way — otherwise the comparison is noise.
A defensible definition names the unit (a deploy of one deployable service to the production environment), the environment that counts as production, and whether failed or rolled-back deploys are included. It is usually derived from deployment or release events in a CI/CD system rather than counted by hand. Because the metric is a rate, it should be reported over a consistent window and, for teams with uneven cadence, expressed as a distribution rather than a single average that a few busy days can distort.
DORA performance tiers
DORA's State of DevOps research groups teams into performance tiers using deployment frequency alongside the other three keys. The bands below are qualitative ranges that DORA has published; the exact thresholds have shifted between annual reports, so treat them as directional categories rather than fixed cutoffs, and always cite the specific report year when quoting numbers.
| Performance tier | Typical deployment frequency |
|---|---|
| Elite | On-demand — multiple deploys per day |
| High | Between once per day and once per week |
| Medium | Between once per week and once per month |
| Low | Between once per month and once every several months |
How to use it without gaming it
Deployment frequency is a team-health signal, not a target to maximize. The moment it becomes a quota, teams split trivial changes into extra deploys to move the number, and the metric stops describing anything real. Use it to spot direction and trend, and pair it with a stability metric so speed and reliability are always in view together.
- Read it with lead time for changes to separate throughput from cycle speed.
- Always show change failure rate and time to restore service beside it.
- Compare a team to its own trend, not to another team with a different deploy definition.
- Prefer the distribution over a single mean when cadence is uneven.
- Never set it as an individual target — it is a system metric, not a productivity score.
Frequently asked questions
Is a higher deployment frequency always better?
Not by itself. Higher frequency usually reflects smaller, lower-risk batches, which is healthy — but only if change failure rate and time to restore service stay stable. A rising deploy count with rising failures is worse, not better, which is why DORA treats throughput and stability as a pair.
What is the difference between deployment frequency and lead time for changes?
Deployment frequency measures how often you ship; lead time for changes measures how long a change takes to travel from commit to production. Both are throughput metrics in the DORA set, but frequency describes cadence while lead time describes cycle duration.
How do you actually measure deployment frequency?
Count successful deployments to production over a fixed window, using deployment or release events from your CI/CD system. The result is only meaningful once you fix the unit — what counts as one deployment and what counts as production — and hold it constant across the teams and periods you compare.
Published by ShipReady Metrics, an evidence-based technology and compliance intelligence platform. This guide is educational and vendor-neutral.