Nobody Is On Call Over a Bank Holiday, So Stop Deploying Like They Are

There's a special flavour of dread that hits at 4:47pm on the Friday before a bank holiday weekend, when the pipeline goes red and the Slack channel goes quiet. If you've been the person holding the laptop while everyone else is at the coast, you already know where this article is going.

Somewhere along the way, UK dev teams convinced themselves that bank holidays are the ideal time to ship. No users about, no stakeholders pinging you, no meetings in the calendar. It sounds sensible. It is, in practice, one of the worst decisions a team can make, and we keep making it anyway.

Quiet Is Not the Same as Safe

The logic goes: fewer users means fewer problems. But deployment risk isn't really about user volume — it's about response capacity. And response capacity is exactly what a bank holiday strips away.

Think about what's missing from a bank holiday deploy:

• Vendor support runs on skeleton crews. That managed database issue or payment gateway outage you need help with? Their next-line support is also on holiday.
• Your incident responders are scattered. The person who knows why the queue consumer dies under load is in the Lake District with one bar of signal.
• Third parties are frozen. Need an emergency change to a DNS record, a compliance sign-off, or a quick word with the client? Nobody's answering until Tuesday.

A production incident on a normal Tuesday is an inconvenience. The same incident on Good Friday is a slow-motion car crash with the handbrake on.

The War Stories All Sound the Same

Ask around and the pattern repeats. The team that deployed a schema migration before the Easter break and spent the weekend watching a replication lag dashboard. The agency that shipped a checkout change before the August bank holiday — peak e-commerce season, incidentally — and didn't fully notice the conversion drop until the following Thursday. The startup whose one on-call engineer rolled back a bad release from a wedding reception.

None of these were caused by bad code alone. They were caused by bad code meeting bad timing.

A Saner Release Calendar

You don't need to stop deploying; you need to stop deploying when your safety net is in the wash.

Hard rules worth adopting:

• No risky or irreversible changes in the 24 hours before a bank holiday. Feature flags and incremental rollouts are fine; migrations and infrastructure changes are not.
• If a deploy must happen, it happens Thursday morning, not Friday afternoon, with at least two people genuinely on call — not "on call but also at a festival".
• Freeze windows go in the team calendar at the start of the quarter, not improvised on the day.

What to do with the idle time instead: bank holidays are actually brilliant for the unglamorous work that requires no rollback plan — documentation, dependency bumps in staging, that refactor branch that's been gathering dust. Low-stakes, high-satisfaction, and nobody's paged when it wobbles.

The Career Angle Nobody Mentions

Here's the bit that doesn't get said in retrospectives: the bank holiday deploy disproportionately falls on the same people. Often the most junior, often the ones least able to push back, often the ones whose bank holiday gets quietly consumed while the person who approved the release enjoys theirs.

If you're a lead, the fix is simple — don't schedule them, and don't reward the heroics when they happen anyway. Celebrating the engineer who saved the weekend from a beer garden teaches your team that self-inflicted incidents are a badge of honour. They aren't. A boring, uneventful bank holiday is the win.

Ship on Tuesday Instead

Code doesn't care when it goes out. Your ability to respond when it goes wrong does. Push the release to Tuesday morning, when the vendors are answering, your colleagues are at their desks, and a rollback takes minutes rather than a miserable weekend.

The deploy will still be there after the long weekend. So will the sun, if you're lucky. Go and enjoy it.