Deployment frequency is monthly and change failure rate is 30%. Which do you attack first and why?

What is being tested

Whether you understand that the two metrics are causally linked rather than independent, and in which direction.

The answer: they are the same problem

The 30% failure rate is substantially caused by the monthly cadence, not despite it.

A monthly release bundles a month of changes. When something breaks:

• The causal set is enormous — hundreds of changes, any of which could be responsible.
• Diagnosis takes hours, because nobody can hold a month of changes in their head.
• Rollback is all-or-nothing: reverting the failure means reverting every good change with it.
• Nobody remembers the details of a change they made three weeks ago.

Smaller batches invert every one of those. This is the consistent finding of software delivery research: throughput and stability move together, and the mechanism is batch size.

So attacking the failure rate directly — more testing, more approval gates, a longer stabilisation period — makes the cadence worse and therefore makes the failure rate worse. It is the intuitive response and it is counterproductive.

What to attack, in order

1. Rollback capability. Before increasing frequency, make reversal cheap and tested. This immediately reduces the impact of the 30% while you address the cause, and it is the prerequisite for everything else.

The specific blocker to check: schema migrations that the previous version cannot read. Expand-and-contract is usually the necessary change.

2. Feature flags, to decouple deployment from release. Now code can ship continuously while exposure remains a decision, which removes the main structural reason for monthly releases.

3. Reduce batch size incrementally. Monthly to fortnightly to weekly. Measure the failure rate at each step — it will fall, and that evidence is what wins the argument for the next step.

4. Canary releases, once frequency is up. A small share of traffic with automated comparison catches problems before full exposure, and it is only practical at reasonable frequency.

5. Then examine the residual failures. Whatever remains after batch size is fixed is the real quality signal, and it points at testing gaps or specific fragile areas.

The diagnostic to run first

Trace one change from commit to production and record where the time goes. The waiting is nearly always concentrated in one or two places — a fortnightly approval board, a shared environment queue, a manual migration process — and that is more useful than any general argument.

The framing for leadership

"We release monthly for safety" describes an intention. The 30% failure rate is the measurement, and it says the approach is not working. The proposal is not "move fast and break things" — it is that smaller changes are easier to verify and cheaper to reverse, which is why frequent deployers have lower failure rates.