Definition
Deployment Frequency
Deployment Frequency is how often a team ships code to production over a given period. It is one of the four DORA metrics and a common proxy for delivery throughput.
What it measures
Deployment Frequency counts the number of times a team releases code to production in a window of time, typically expressed as deploys per day, per week, or per service. Elite-performing teams in the DORA research deploy on demand, often many times a day, while lower-performing teams deploy weekly or monthly.
It is a throughput signal. A higher rate usually reflects smaller batch sizes, more automation in the pipeline, and shorter feedback loops between writing code and seeing it run in production.
How to measure it
The cleanest source is your deployment pipeline. Count successful production deployment events per service over the window and divide by the number of days or weeks. If you deploy through CI/CD, every production release job or environment promotion is one data point, so reading the pipeline's run history gives you the raw count directly.
Without a pipeline event log, you can approximate from git. Count merges to your release branch, tagged releases, or commits that reach the production-tracking ref, then align those to actual production cutovers. Be careful to count production deploys only, and to separate them per service so a busy monolith does not mask a rarely shipped component.
Decide upfront whether a rollback or hotfix counts as a deploy, and whether you measure per service or per team. Hold that definition steady, because most of the noise in this metric comes from inconsistent counting rather than real change.
What it does not tell you
Deployment Frequency tells you how often you ship, not what you shipped or whether it mattered. A team can deploy ten times a day and move nothing that the business cares about: config flips, dependency bumps, copy tweaks, and churned-then-reverted work all inflate the count. The number rewards motion, and motion is easy to manufacture.
It is also silent on direction. Frequent deploys spread evenly across low-value maintenance look identical to frequent deploys concentrated on the initiative that decides the quarter. The metric cannot distinguish a team shipping fast toward the wrong goal from one shipping fast toward the right one, and gaming it is trivial by slicing releases thinner.
This is the gap Execution Intelligence closes. The question for a CTO is not how many times you deployed but what each deploy advanced, who did the work, and what it cost against the outcome it was meant to produce. Reading frequency alone measures the speed of the pipeline. Reading what is actually being built and why measures whether the team is executing on strategy.
How InteliG uses it
InteliG computes Deployment Frequency from real git and deployment history with no manual instrumentation. It reads your commits, pull requests, and production deploy events as they happen, so the rate is a byproduct of the work itself rather than a dashboard someone has to maintain.
From there Cognis connects each deploy to the initiative the work belongs to, the contributors who shipped it, and the cost it carried. That turns a raw throughput number into an answer a CTO can act on: not just how often you are shipping, but which strategic bets your deploy cadence is actually moving and what they are worth.
Related terms
- Lead Time for Changes — Time from a committed change to it running in production.
- Change Failure Rate — Share of deploys that cause a production failure or rollback.
- Execution Intelligence — Reading how a team actually executes, connecting code to strategy and cost.