You Ship Once a Month and Call It Stability. It Isn't.

TL;DR: The monthly release doesn't feel safe because it is safe. It feels safe because the danger is scheduled. Each release carries a month of accumulated change, which is why release day needs a war room, why rollback is unthinkable, and why lead time is measured in weeks. The DORA research is blunt about this trade: speed and stability rise together. Elite teams deploy on demand at roughly 5% change failure while monthly-or-slower teams fail around 40%, because the risk was never in deploying. It was in the batch. The cure is a sequence: measure the real cadence from the deploy log, shrink the batch, make the pipeline boring, and let frequency rise as a side effect.

You know it's release week because the calendar says so. There's a freeze, because change is dangerous now. There's a spreadsheet checklist with a name next to each row. There's a war-room channel, staffed, because history has taught everyone that something in this release will misbehave. Nobody knows what, since the release contains a month of everything: two features, forty fixes, a dependency bump someone snuck in, and a migration everyone is quietly afraid of.

The sentence doing all the damage gets said with genuine conviction in every planning meeting: "We can't deploy more often - it wouldn't be stable." The causality is exactly backwards. The releases aren't dramatic because shipping is dangerous. They're dramatic because a month of change in one envelope is the danger, and the drama then justifies the batching that created it. The loop has a shape: fear → batch → bigger release → worse failure → more fear. It will run until someone shrinks the batch.

The stability you feel is risk you're storing

Hold your rate of code production constant and deployment frequency is just the inverse of batch size: ship monthly and every release carries ~4 weeks of merged work. That single variable explains most of the pain you're attributing to fate:

• Failure diagnosis is a lineup of hundreds. When a ten-change deploy breaks, the suspect list has ten entries; when a month-of-everything deploy breaks, the on-call engineer is bisecting history at 2am. This is why change failure rate and recovery time degrade together with cadence, and why how you define recovery suddenly matters so much to monthly shippers.
• The numbers back the loop, not the fear. DORA's 2024 report found elite performers deploying on demand with change failure rates around 5%, while low performers deploying between monthly and semi-annually sat near 40%. (That was the final year of the elite/high/medium/low bands.) Speed and stability are not a trade-off; they're the same capability wearing two hats. The full band table, and the honest caveats around it, are in the deployment-frequency benchmarks breakdown.
• Big batches rot upstream too. A month-sized release is fed by big merges, and reviewer effectiveness collapses on oversized changes: the Cisco data puts effective review in the low hundreds of lines at a time, and LinearB's benchmarks band elite PR size under 100 changed lines. So the batch doesn't just explode on landing; it degrades every review that built it. Small PRs are the raw material of a shippable batch.
• Lead time becomes an era. Work merged on the 3rd waits for the release on the 30th: finished, paid for, delivering nothing. That is the gap between cycle time and lead time stretched to weeks by policy. It is also the reason release dates slip so theatrically: a train that leaves monthly makes every missed connection a month long.

DORA's small-batches capability states the mechanism plainly: small batches mean fast feedback and cheap course correction. A monthly batch means you find out what a month of decisions was worth, all at once, in production, on a Thursday.

How to increase deployment frequency (the actual sequence)

Skip the slogans, and skip "deploy daily starting Monday." This is a sequence, and each step makes the next one safe:

1. Measure the real cadence and lead time from the log. Deploys per week from your deployment events, and merge-to-production time per change, over the last quarter. Standup answers flatter this number routinely; the delivery scoreboard is only worth having if it's built on the log. This baseline is also your proof later, when someone claims the old way was safer.
2. Shrink what feeds the pipeline. One logical change per PR. This is the least glamorous step and the one that pays the most: batch size at deploy is decided at branch.
3. Make the pipeline boring. Automate the checklist out of existence: one command to ship, tests you actually trust, and a rehearsed rollback path. The measure of done is emotional. Deploying should feel like running the test suite.
4. Decouple deploy from release. Feature flags separate shipping code from announcing features. Half the fear of frequent deploys is really fear of premature launch; flags delete that coupling, and incomplete work can ship dark instead of blocking the train.
5. Tighten stepwise, watching the failure rate. Monthly → fortnightly → weekly → on green. At each step, watch change failure rate next to frequency: if it holds while cadence rises, the fear was the batch, and now you have the receipts. Expect the freeze rituals, and the midnight-deploy heroics they generate, to become unnecessary before anyone formally cancels them.

The full four-key context for what "good" looks like while you move - and what the other metrics should be doing meanwhile - is in DORA metrics explained.

How you'd actually see this in Busfactor

The baseline in step one is exactly the number orgs argue about instead of measuring. Busfactor counts deploys per week from your recorded deploy events (deployment API, CI workflow runs, or release tags), so the cadence conversation starts from the log instead of the vibe. It renders on a DORA scoreboard alongside lead time, change failure rate, and recovery, with a property most dashboards skip: every tile carries a trust disclosure. If your recorded deploy history is younger than the window you're looking at, the page says so and withholds the deploy-dependent numbers rather than endorsing them. Failure-rate and recovery tiles are labeled as disclosed proxies until a measured error-tracking source is connected. The published industry scale is shown even while your own tile says "awaiting" - here's the yardstick, and we're not pretending to measure you against it yet. As deploy signal lands, the tiles light up on their own.

The honest limits: Busfactor sees the deploys that emit an event. If production changes by SSH-and-pray, the log is empty, the page will say awaiting a deploy source, and the first improvement it can offer is making your deploys observable at all. It also can't decide what a "deploy" should mean in your architecture (a monolith and thirty microservices produce incomparable counts for identical discipline), which is why the number is always shown against your own history first and the industry scale second. What the data can do is settle the argument this article is about: whether your stability is real, or just scheduled.

The door

Pull the last quarter's deploy log this week and compute two numbers: deploys per week, and merge-to-production time. If the second is measured in weeks, your "stability" is a batch-size artifact wearing a virtue costume. Every step of the cure above is standard, boring, proven practice. Then, if you'd rather the cadence, the failure rate, and the honesty disclosures watch themselves while you shrink the batch, get your org's free read. The fear was never data. Now the rebuttal can be.