Deployment Frequency

There was a time when deploying was a monthly event. A date got picked, everything built by that date was gathered up, and the servers went down and back up at night. Shipping once took a lot of manual work, so teams naturally batched changes, and batching made each release bigger.

The trouble with that shows up the moment something breaks. Thirty changes go out on a Friday night and Saturday morning brings support tickets saying payments are failing. Nobody knows which of the thirty caused it. Removing them one at a time eats half a day, and meanwhile the twenty-nine healthy changes sit undelivered along with the broken one.

So teams moved toward shipping in smaller pieces. When one change goes out at a time, a failure has exactly one suspect and a rollback takes five minutes. Deployment frequency is the number that confirms from the outside whether the shift actually happened. Everyone says they want smaller releases; counting last month's deploys shows how far the words are from the practice.

Pick a period and count the deploys that reached production during it. Thirty-two deploys over four weeks is eight per week; a team that ships monthly is at one per month.

Three counting rules keep the number honest.

1. Only production counts. Anything pushed to a development or internal review environment never reached users, so it drops out.
2. Shipped code counts as one deploy. The ambiguous case is code that went out with the feature switched off behind a feature flag. If that code is running on production servers, it's a deploy. Turning the feature on is a separate event.
3. A rollback counts as one too. It changed production, and how often you roll back is what change failure rate measures separately.

The counting itself is easy — read the deploy log. The hard part is agreeing inside the team on what counts as one. If the product is split into three services that deploy independently, treating that as three deploys or as one bundle changes the number by a factor of three. Without a written rule, quarters measured on different yardsticks end up in the same table.

Teams usually express it per week or per day. Putting a monthly shipper and a five-times-a-day shipper on the same unit pushes one of them below the decimal point, where it's hard to read. Whichever unit gets picked, keeping it fixed matters more than the choice, because a unit that changes between quarters hides the trend the number exists to show.

Comparing against your own last quarter beats memorizing thresholds. Research puts the strongest organizations at multiple deploys per day and the weakest at once every few months, but the boundaries between those bands shift between survey editions. A team that went from monthly to weekly improved clearly, even if it lands in no elite bracket.

This number also comes with a condition: don't read it alone. Deployment frequency means something only when time to restore service and change failure rate sit next to it. Frequency rising from 2 to 20 per week while failure rate goes from 5 percent to 30 percent isn't an improvement, it's skipped verification. The reverse case — flat frequency with a failure rate near zero — can mean a team playing it safe by shipping nothing.

When the number is low, the place to look is usually the same. Count how many human steps one deploy takes. With three manual approvals and an hour of manual checks in the way, no amount of willingness produces several deploys a day. CI/CD is the setup that checks a change automatically and carries it to the server when nothing is wrong, and every manual step removed from it pushes the number up on its own. Fixing the bottleneck rather than setting the number as a goal is how the metric is meant to be used.

"Our deployment frequency was once a week last month. That's because the deploy process has three manual approvals in it."

Using the number as a clue for locating a bottleneck rather than as a verdict.

"Let's not set deployment frequency as a target. Empty deploys would raise it just fine."

Pointing out that a metric turned into a goal stops measuring.

"Frequency doubled this quarter and the failure rate held. That one went up the right way."

The judgment came from reading it alongside its stability counterpart.

Pagedeck first measured this back when it shipped monthly, which put the number at one. Theo wrote down the steps in a single deploy and counted eleven, seven of which a person did by hand: running tests, writing up a change list, collecting approvals, opening a session on the server and typing commands.

Those seven went away one at a time over two quarters. There was no grand plan — the step that took the most hands went first. Pagedeck now deploys about eight times a week, and the change failure rate did not rise over the same period. That pairing is why Grace put both numbers side by side in the board deck. One number alone says the team got faster. Two say it got faster while breaking things less often.

The most common assumption is that shipping more often makes a system less stable. More changes to production sounds like more chances to break it. In practice it runs closer to the opposite. Each release is smaller, so a failure narrows to one suspect and reverting is easy. The team that shipped thirty changes at once spends half a day on an incident; the team that shipped one gets back to the previous state in five minutes. Leave the assumption in place and the team batches even harder, which makes the eventual incident bigger.

Treating the number itself as the goal is the other frequent mistake. It looks like an easy metric to move, so it ends up as a quarterly target. But ten empty deploys a day raise it just as well. A team handed that target usually splits one change into three and ships it three times — six months later the number has tripled while what users receive hasn't changed. The thing worth raising is how fast a change reaches users, and that only becomes visible with all four metrics together.