Engineering Delivery

Deployment frequency

Note: New to DORA? Start with What is DORA?, a five minute introduction that assumes no prior knowledge.

Deployment frequency is how often your team puts new code in front of real users. It is one of the five DORA metrics, and a simple count tells you a lot: teams that deploy often tend to ship smaller, safer changes and get feedback sooner.

What is deployment frequency?

DORA defines it as:

"The number of deployments over a given period or the time between deployments."

A deployment is the moment a change goes live in production, the real system your customers use. Deployment frequency simply counts those moments. You can say it as a count ("12 deployments a week") or as a gap ("one deployment every two days"). Both describe the same thing.

Take a team of six building an online booking app. In March they deployed 26 times, roughly six times a week. In January, before they automated their release steps, they deployed twice in the whole month. Same team, same product. What changed is how often finished work reached customers.

Deployment frequency is one of DORA's three throughput metrics, the ones that describe how fast changes move through your system. The other two are change lead time and failed deployment recovery time. For the full picture of all five metrics, see The five DORA metrics.

Why does it matter?

It can sound like a speed contest. It is not. Deploying often matters for three practical reasons.

Smaller changes are safer. If you deploy twice a month, each deployment carries two weeks of work from several people. When something breaks, you have a lot to search through. If you deploy every day, each deployment holds a day's work, so a problem is easier to find and easier to undo.
Customers get value sooner. A fix that sits finished but undeployed for three weeks helps no one for three weeks.
You learn faster. Every deployment is a chance to see how real users react. More deployments mean more chances to find out you were wrong while the change is still small and cheap to adjust.

DORA's research backs this up. In the 2024 report, the highest performing group deployed on demand, several times a day, and also had the lowest change fail rate of any group (2024 report, p.13). Speed and stability tend to go together, not against each other.

How do you measure it?

Count the deployments to production in a period, then divide by the length of the period. Per week is the most useful unit for most teams.

To get a number you can trust, agree on a few things first.

What counts as a deployment. For some teams it is a run of the production deployment pipeline. For others it is a merge to the main branch that ships automatically, or a tagged release. Pick the one that matches how code actually reaches your users, and keep it the same over time.
Production only. Deployments to a test or staging environment do not count. Only changes that reach real users do.
Per application or service. DORA asks you to measure "in the context of the application or service your team is delivering" rather than lumping many teams together (DORA metrics guide). A service is one deployable part of your product, such as a payments service or a mobile app.
Failed deployments still count. A deployment that had to be rolled back was still a deployment. How often deployments fail is measured separately, by change fail rate.

Where does the data come from? Usually from your deployment tool or CI/CD system (GitHub Actions, GitLab, Argo CD and similar), or from your code host if merges deploy automatically. You do not need to count by hand.

Tip: A week with zero deployments is data too. Leaving quiet weeks out makes the number look better than it is.

What does good look like?

DORA groups survey answers into performance levels each year. The 2024 report (p.13) found four groups for deployment frequency:

Level	Deployment frequency	Share of respondents
Elite	On demand (multiple deploys per day)	19%
High	Between once per day and once per week	22%
Medium	Between once per week and once per month	35%
Low	Between once per month and once every six months	25%

The 2025 report shows how all respondents answered (2025 report, p.20):

How often the organisation deploys	Share of respondents
On demand (multiple deploys per day)	16.2%
Between once per hour and once per day	6.5%
Between once per day and once per week	21.9%
Between once per week and once per month	31.5%
Between once per month and once every six months	20.3%
Fewer than once per six months	3.6%

So if you deploy at least once a week, you are ahead of more than half of the teams DORA surveyed in 2025.

Read these numbers as a map, not a target. DORA is clear on this: "The best teams are those that achieve elite improvement, not necessarily elite performance" (2024 report, p.15). The most useful comparison is your own team against its own past. You can read more in DORA performance levels.

How do you improve it?

Deployment frequency usually goes up by itself once deploying becomes small, boring and safe. Work through these in order.

Ship smaller changes. A change that does one thing is quicker to review, test and deploy. DORA lists working in small batches as a core capability. See Change size for practical ways to split work.
Automate the deployment itself. If deploying means a checklist and a person at a keyboard, people will batch work to avoid doing it often. Deployment automation turns a deploy into one button, or no button at all.
Build trust with automated tests. Teams deploy often when they are confident each change works. Test automation and continuous integration give that confidence on every change.
Deploy once checks pass. Instead of waiting for a weekly release window, let every change that passes its checks go out. This is the heart of continuous delivery.
Separate deploying from releasing. A feature flag lets you deploy unfinished work switched off, and turn it on for users later. You stop holding back finished code while a larger feature is still in progress.
Lighten heavy approvals. DORA found that heavyweight external change approval boards make delivery slower and found no evidence that they lower change fail rates. Peer review inside the team's normal workflow works better. See streamlining change approval.

Tip: If you are not sure where to start, look at what happens between "the code is merged" and "the code is live". Waiting there is usually the first thing to remove. Improving software delivery explains how to find your biggest constraint.

Common mistakes

Making it a target. DORA warns against "setting metrics as a goal" (DORA metrics guide). Once the number is the goal, it is easy to game: split one change into ten empty deployments and the chart looks great while nothing improved.
Reading it alone. More deployments are only good if they do not break more often. Always read deployment frequency next to change fail rate. DORA calls this the danger of "having one metric to rule them all".
Comparing very different systems. A mobile app that ships through an app store and a web service that deploys continuously will never have the same frequency. DORA warns against "making disparate comparisons". Compare a service with its own past.
Counting test environments. Deployments to staging say nothing about what reached users.
Blaming a team for a slow number. Low frequency is almost always caused by the system around the team: manual steps, approval queues or fragile tests. Fix the system.

How Solidafy measures it

In the Engineering Delivery app, deployment frequency is shown as production deploys per week, over the period you choose, next to the period you compare it with.

A deploy is whatever the deployment rule in Settings says counts: detected for each repository, a production deployment, a merge to the main branch, or a tagged release.
A deploy counts whoever merged it, including a bot.
The chart reads "Production deploys a week, by month. Higher means faster feedback."
The default goal comes from your own baseline: 10% better than your current value, once the app has measured it. DORA's 2025 report publishes no target, so no published figure is used. You can accept the default, edit it, or set your own goal. A default is a suggestion, never a grade, and it never raises an alert on its own.
Nothing is estimated. If no deployment data is connected, the tile says so rather than guessing.

You find deployment frequency on the Overview and on the Speed page; the Speed guide explains what to do when it drops.

Learn more

From DORA:

Related Solidafy guides: