The Long Weekend Release Drill: Ship on Friday, Sleep on Monday

There is a special kind of optimism in shipping a change on the Thursday before a UK bank holiday. The office is half empty, the release ticket says low risk, and someone says the magic words: we'll fix it Tuesday if anything happens. That is not a release strategy. It is a bet against your own monitoring.

As we head into the Christmas bank holiday stretch in 2026, with Boxing Day and New Year cover already looking thin, the long weekend is a load test you did not ask for. Traffic patterns shift, support rotas shrink, and the people who know the weird bits of your stack are on a train to somewhere with no signal. The goal is not to make the weekend exciting. The goal is to make Monday boring.

Start with the calendar, not the code

UK bank holidays are not one neat national event. Scotland has different dates, some councils treat the Christmas and New Year period differently, and retail traffic can spike before the closure rather than during it. Before you touch a load balancer, map the actual long weekend: which days are quiet, which are peak, and who is on call for each one. Publish a deployment freeze window and make it boringly explicit. Critical fixes only, with a named approver who is not also the person doing the deploy. If nobody can approve a change on a Sunday, that is useful information.

Warm the cache before the crowd arrives

A cold cache is a performance bug with good PR. After a deploy or a CDN purge, your first real users become the cache warmer, and they get the slow version. Write a small warming script that hits the top routes from your analytics: homepage, category pages, search endpoints that are safe to call, and the handful of product or content pages that always get linked from email. Run it after every purge, not just on Fridays. Check that it respects Cache-Control and does not hammer a third-party API. A simple loop with curl is enough:

for path in / /search /help /pricing; do
  curl -sS -o /dev/null https://www.example.co.uk${path}
done

If you use a CDN, make sure the warmer goes through the same edge path as users. Warming origin directly proves very little.

Load-test like a bank holiday, not a Tuesday

Most load tests are theatre. They fire a thousand requests at the homepage and call it resilience. A bank holiday test should model the behaviour you actually expect: more read traffic, longer sessions, fewer support staff, and a payment provider that may be slower than usual. Use a staging environment with production-like cache and database size, and keep the test short enough that nobody has to babysit it. A k6 script can be brutally simple:

import http from 'k6/http';
import { sleep } from 'k6';
export const options = { vus: 50, duration: '5m' };
export default function () {
  http.get('https://staging.example.co.uk/');
  http.get('https://staging.example.co.uk/search?q=shoes');
  sleep(1);
}

Watch the p95, not just the average. Check error rates at the edges and the database. If the test brings down staging, good. You have found the problem before a real customer did.

Freeze deployments, not judgement

A deployment freeze is not an excuse to ignore bugs. It is a rule that says the cost of an unplanned change is higher than the benefit of shipping it now. Keep a short list of exceptions: security fixes, payment failures, and anything that stops staff serving customers. Everything else waits. Use feature flags for the changes you absolutely must ship, and make sure the flag defaults are safe if the flag service is having a bad day. A flag that calls a remote API on every request is not a safety net.

An on-call rota that respects the long weekend

Skeleton crews are fine if they are planned. They are not fine if one person is silently holding the pager for four days. Publish the rota, name a deputy, and give the on-call engineer a handover that includes known risks, recent changes, and the exact commands for a rollback. Check that alerts go somewhere a human will see them. A Slack channel with no escalation path is just a diary. If your team is small, consider a mutual-aid arrangement with another team or a supplier support contract. The bank holiday is not the time to discover that your only database expert is at a wedding.

A rollback checklist you can read at 8am

Keep it short enough to use when you are half awake:

• Confirm the failing version and the last known good version.
• Check whether the database migration is reversible. If not, stop.
• Disable the relevant feature flag before redeploying.
• Roll back the application, then clear or warm the cache deliberately.
• Verify the top five user journeys, not just the health check.
• Post a short note in the incident channel with time, action, and owner.
• Decide whether to pause the freeze for a follow-up fix or wait until normal service.

The Tuesday trap

We'll fix it Tuesday is not a plan. Tuesday is when the queue of ignored problems comes back with interest. If you are not confident enough to support a change over a long weekend, do not ship it on Thursday. If you are confident, prove it with a load test, a warm cache, a named on-call engineer, and a rollback you have actually rehearsed. Then go and enjoy the bank holiday. Monday morning should be dull. That is the whole point.