What Is Deployment Frequency? A Practical Guide for Startup Engineering Teams

Deployment frequency is how often your team successfully releases code to production. It is one of the four DORA metrics used to gauge software delivery performance, and its real value is not speed for its own sake: it is a proxy for how large your changes are when they ship.

If you lead engineering at a startup, you probably already track merges, tickets closed, or sprint velocity. Deployment frequency sits closer to the customer, because it counts only work that reached production. This article covers how to define and measure it, how to read benchmarks without being misled, where teams go wrong, and how to ship more often without wearing people out.

Deployment Frequency, Defined Precisely

The plain definition is the count of successful production deployments over a time window, usually expressed per day or per week. DORA stands for DevOps Research and Assessment, the research program that identified four metrics that together describe software delivery performance:

• Deployment frequency: how often you release to production.
• Lead time for changes: how long a change takes to go from commit to running in production.
• Change failure rate: the share of deployments that cause a failure needing a fix or rollback.
• Time to restore service: how quickly you recover when a production failure occurs.

The first two measure throughput; the last two measure stability. The metrics came out of the research behind the book Accelerate (Forsgren, Humble, Kim, 2018) and the annual State of DevOps reports. DORA is now part of Google Cloud.

What counts as a deployment

A deployment is a release that reaches production users. A merge to main is not one. Neither is a push to staging, and neither is flipping a feature flag on code that already shipped. The ambiguity matters because it changes the number dramatically.

Suppose a team merges 40 pull requests in a month, pushes to staging 25 times, and releases to production 12 times. Depending on which event you count, deployment frequency is 40, 25, or 12 per month. Only the last reflects how often customers receive changes. Pick the definition once and write it down.

Why it works as a batch size proxy

Teams that deploy often tend to ship small changes. Small changes are easier to review, easier to test, and easier to roll back, because there are fewer places for a problem to hide. A team that deploys once a month is usually bundling weeks of work into each release, which raises the cost of every failure. That relationship, not the raw count, is why the metric deserves attention.

How to Measure It From the Data You Already Have

The arithmetic is simple. Suppose your team made 18 production deploys over 4 weeks. Divide 18 by 4 and you get 4.5 deploys per week. Converting to a daily figure, assuming five working days, gives about 0.9 per day. Choose the unit that keeps the number readable: a team at 4.5 per week should report weekly, while a team shipping many times a day should report daily.

Where the events live

Look for a record that says "this version went to production." Common sources include:

• CI/CD pipeline events from the job that runs the production deploy step.
• GitHub Deployments or GitHub Releases, if you create them.
• Git tags that mark release versions.

If none of these are recorded, merges to the main branch are a stand-in. They overstate frequency whenever merged code waits for a later release, so treat a merge-based figure as an upper bound and label it that way.

Multiple services and edge cases

With a monorepo or several services, count deployments per service first, then roll them up. A single commit that triggers five service deploys is five deployments if each is independently released, but one if they ship as a single unit. Decide which rule applies and stick to it.

Also decide in advance how to handle hotfixes and rollbacks. A reasonable default is to count a hotfix as a deployment, since it reaches production, and to exclude a rollback from the frequency count while recording it under change failure rate. The specific choice matters less than applying it consistently.

Smooth the noise

One week is a weak sample. Holidays, a company offsite, or an incident can halve a week's count without telling you anything about delivery health. Look at the median across several weeks, or a rolling four-week average, and watch the direction of the trend rather than any single data point.

What Good Looks Like: Reading the Benchmarks Carefully

DORA has historically grouped teams into performance tiers (elite, high, medium, and low), with deployment frequency ranging from on-demand multiple deploys per day at the top to less than once per month at the bottom. Those thresholds and even the tier framing have shifted between annual State of DevOps reports. Before you quote any figure, check the latest DORA report directly, and describe any number as accurate "as of" the report year. As of 2026, treat any remembered threshold as something to confirm, not a fact to repeat.

Context beats the tier label

A realistic cadence depends on what you ship and to whom:

• A B2B SaaS web app with a single deployable can often release many times a day.
• A product sold to enterprise customers may coordinate releases around customer change windows or contractual notice.
• A mobile app is gated by app-store review, which caps how often users can receive a new binary, though server-side changes can still ship freely.
• A regulated product with mandatory validation steps will have a slower floor, and that is not a failure.

Measuring a mobile team against a web team's number produces a meaningless comparison.

Your own trend is the best benchmark

The most useful comparison is your team against its own history. A steady cadence that matches your product constraints is healthy. A cadence that is drifting downward deserves a question.

Consider a hypothetical example. Over two months, a team's merge volume climbs by a third, but deployment frequency stays flat at about four per week. Merges are rising and releases are not, so changes are accumulating and shipping in larger bundles. That pattern usually precedes riskier releases, longer reviews of release candidates, and harder debugging when something breaks. The flat line is the signal, even though no tier label would flag it.

Common Ways Teams Misread Deployment Frequency

Turning it into a target

Goodhart's law applies directly: when a measure becomes a target, it stops being a good measure. Tell a team to hit ten deploys a week and some will split changes into trivial pieces, ship configuration no-ops, or release empty changes to inflate the count. The number rises and delivery does not improve. If you set a goal at all, set it on outcomes such as smaller lead time or fewer failed releases.

Reading it alone

Frequency without stability is half a picture. A team that deploys twenty times a week with a high change failure rate and slow recovery is fast and fragile, which is not success. Always read it beside change failure rate and time to restore service. Healthy improvement raises or holds frequency while failure rate stays flat or falls.

Comparing people and teams

Ranking individuals or teams by deploys ignores real differences. A team owning a payments service with strict review requirements will deploy less often than one owning a marketing site, and should. Deployment frequency describes a system and its delivery pipeline, not an individual's productivity. Using it to evaluate people also pushes them toward the gaming described above.

Treating low frequency as a diagnosis

A low number tells you something is slowing releases; it does not tell you what. Common causes include:

• Pull requests waiting days for review.
• Flaky tests that force reruns and erode trust in CI.
• Manual release steps that only one person knows how to run.
• Caution left over from a past incident, where the team now batches changes to feel safer.

Each has a different fix. Find the actual constraint before changing process, or you will optimize the wrong step.

Practical Ways to Deploy More Often Without Adding Risk

Shrink the batch

Smaller pull requests are the most reliable lever. Pair them with trunk-based development, where engineers merge to a single main branch in short-lived branches that last a day or two rather than weeks. Long-lived branches create large merges and delayed integration, which is exactly the pattern that keeps frequency low.

Automate the release path

If deploying takes a checklist and a nervous person, it will happen rarely. Aim for CI that runs reliably, a deploy triggered by a pipeline rather than by hand, and a one-step rollback. When undoing a release is cheap, shipping one becomes much less frightening.

Separate deploy from release

Feature flags let you ship unfinished work to production switched off, then enable it when it is ready. This decouples the technical act of deploying from the business decision to release, so incomplete features no longer block the pipeline. Remember to clean up old flags, or they become their own source of complexity.

Watch the people, too

Pushing for speed while pressure rises can hurt a team even as the chart improves. Burnout tends to show up first as slowing momentum and disengagement, and only later as missed delivery. Track team momentum and wellness next to the metric so you notice the cost of a faster cadence early.

Where Progress fits

Progress is an AI-native engineering intelligence platform that reads activity from tools like GitHub and Linear. It assesses deployment risk and change pressure from merge volume and code churn, which helps you spot the flat-frequency, rising-merges pattern described earlier. It also flags stalled work that may be holding releases back, and reports on team momentum and morale, so you see the human side alongside the delivery signals.

Setting a Baseline Before You Set a Goal

Deployment frequency is a trend signal about batch size and delivery health, not a scoreboard. Its job is to tell you when changes are piling up, and it can only do that if you measure it consistently.

Start with three steps. First, define what counts as a deploy for your product and write the rule down, including how you treat hotfixes and rollbacks. Second, record a four-week baseline so you know where you actually are. Third, pair the number with change failure rate before you consider any target, so a faster cadence never comes at the cost of stability.

If you want those signals pulled together from your existing tools, Learn more about our services.