Guide
Deployment frequency
Deployment frequency is how often an organisation successfully releases changes to production. It is the simplest of the four DORA metrics to state and the one most commonly measured wrongly, because a great many tools substitute merges to the main branch for actual deployments.
Why the proxy problem matters so much
If your team merges continuously and releases fortnightly, counting merges will report you as an elite performer while you are in fact deploying twenty-six times a year. The gap between those two pictures is the entire question the metric exists to ask.
It matters because deployment frequency is really a proxy for batch size. Frequent deployment means small changes, which means easier diagnosis when something breaks, which is why the metric correlates with the stability measures rather than trading off against them. Measuring merges instead measures how the team uses branches, which is not the same thing at all.
What actually moves it
Deployment frequency is a downstream symptom. It rises when the things blocking release get cheaper: automated testing that people trust, a rollback path that works, feature flags that decouple deploying from releasing, and a change-approval process proportional to the actual risk.
It falls when releasing is expensive or frightening. A team deploying monthly is almost never doing so because it prefers to — it is usually because the last few releases were bad, or because the approval process takes a fortnight. Treating the number as a target rather than a symptom produces theatre.
Reading it honestly
Some contexts genuinely cannot deploy on demand — regulated environments, embedded firmware, software shipped to customers who install it. The metric is still useful in those settings as a trend, and the bands are not.
It is also worth separating deployment from release. A team using feature flags may deploy many times a day and release to users weekly, and both figures are legitimate. Say which one you are reporting.
Where this measure goes wrong
Each of these produces a number that looks reasonable and is not.
Counting merges to main
The single most common error. It measures branching strategy, not release cadence.
Counting deployments to every environment
Staging deployments inflate the figure enormously and describe nothing about delivery to users.
Treating it as a target
Deployment frequency is a symptom of release cost. Pushed as a goal, it produces empty deployments.
Ignoring failed deployments
The metric is successful releases to production. Counting attempts flatters a team with a flaky pipeline.
Frequently asked questions
What is a good deployment frequency?
DORA bands elite as on demand or multiple times per day, high as daily to weekly, medium as weekly to monthly. But context dominates: for a team shipping installed software, weekly is excellent, and the band is not the useful signal — the trend is.
Should we count deployments or releases?
Whichever you choose, be consistent and say which. If you use feature flags the two genuinely diverge, and reporting a blended figure means nobody can interpret the number.
Does deploying more often make us less stable?
The DORA research finding is the opposite: throughput and stability rise together. Frequent deployment means smaller changes, which are easier to diagnose and to reverse. The trade-off most people assume does not appear in the data.
See deployment frequency for your own teams
Pacia computes this from your repositories and issue tracker, banded and trended, with a drill-down to the work behind every figure.