It usually happens on a Thursday. Someone merges a small change — a tweak to checkout validation, a new redirect rule — and then heads off for two weeks in Cornwall. The following Monday, support notices that a slice of orders are failing. The person who understands that service is 300 miles away with one bar of signal, and the two people who could approve a rollback are on a ferry.
A summer deployment freeze is not about banning work or wrapping the codebase in bubble wrap. It is about shrinking the blast radius at the exact moment your team is at half strength. What follows is a checklist you can adapt to your own release process, whether you deploy ten times a day or once a fortnight.
Decide what the freeze actually covers
"Freeze" means different things to different teams, and vague rules get argued about at 5pm on a Friday. Write down which changes stop and which keep moving.
- Stopped: customer-facing feature releases, framework upgrades, dependency bumps that touch payment or authentication code, infrastructure changes, anything that alters a database schema.
- Allowed with a second pair of eyes: security patches, copy and pricing corrections, changes to a feature sitting behind a flag that is off by default.
- Always allowed: fixing an incident already in progress, restoring a backup, turning a flag off.
Publish the dates, the tiers and the name of the person who can grant an exception. One named approver beats a committee every time.
The emergency path
Even in a freeze, something occasionally has to ship. Agree now on what an emergency change looks like: a single small commit, a peer review that can be done over a video call, a deploy window early in the day, and someone watching the dashboards afterwards rather than closing their laptop. If the fix cannot be made small, it is a rollback, not a release.
Clear the decks before the freeze begins
The fortnight before the freeze is where most of the value is created. Treat it as a deadline, because it is one.
Finish and ship the risky work now. Database migrations, payment provider changes and anything touching authentication should be live, observed and stable for several days before the first person leaves. Do not let a migration land on the final Thursday and call it done because the tests passed.
Cut and tag the release branch a few days early, and confirm you can deploy that exact artefact again without rebuilding it. Then look at what is still in flight: if there is a half-finished feature branch merged into main, either complete it behind a flag or park it. Half-merged is worse than unmerged.
Make rollback the boring option
A rollback plan that lives in a wiki page and has never been run is a wish, not a plan. Spend an afternoon in the quiet weeks making yours genuinely dull.
Rehearse it
Run a rollback in staging with production-like data. Time it. Write down the command or the button, who is allowed to press it, and what "rolled back" actually looks like — a green pipeline, a healthy error rate, a customer journey completing? If a rollback takes longer than the incident it fixes, people will hesitate when it counts.
Handle the database first
Code rolls back; data often does not. Prefer expand-and-contract migrations: add the new column, keep the old one, backfill, switch reads and writes, and only remove the old column in a later release. That way a rollback needs the application artefact and nothing else, with no restore from backup.
Prefer flags to deploys
If a feature can be switched off from a config panel, you do not need a deployment at all. Make sure the flag is documented and that whoever is on call knows where the switch lives. A flag nobody can find is a liability dressed up as safety.
Monitoring and alerts when the office is quiet
A quieter office means fewer people noticing that something feels wrong, so your alerts have to do the noticing. Before the holidays, work through this:
- Trim the noise. Silence alerts that fire weekly and get ignored; they train people to dismiss pages.
- Verify synthetic checks on your three most valuable journeys — sign-up, login, checkout — running from outside your own network.
- Test the routing. Does a page still reach a human at 2am, and does that human know what to do next? Send a test alert through the whole path.
- Build a holiday dashboard: error rates, latency, queue depth, failed payments, plus deploy markers for anything shipped in the last fortnight.
- Adjust thresholds only where traffic genuinely drops. Lowering a threshold because fewer users are around is how real outages get missed.
Handover, access and the break-glass path
Write the runbook as if the reader has never seen the system, because in August they probably have not. Link the repository, the deploy pipeline, the dashboards, the incident channel and the vendor support numbers in one place, and click every link to check it works.
Access is the other half of the job. No service should depend on one person's credentials while they are away. Confirm that at least two people can deploy, roll back, rotate a secret and reach the hosting provider's console. Store break-glass credentials in the team password manager with an audit trail, and state plainly who may use them and when. If an agency or contractor holds the only admin account, sort that out before the freeze, not during an incident.
Then look after the people left behind. Rotate on-call fairly, keep the rota visible, and give whoever is on call permission to step back from feature work. A rota that quietly lands on one person for three weeks is how a calm month turns into a resignation.
The Friday-before checklist
Half an hour, before the last of you logs off, covering the things that are easy to forget and expensive to rediscover.
- Freeze dates posted in the team channel and in the shared calendar.
- Release branch tagged, artefact stored, rollback rehearsed and documented.
- Migrations complete and stable for several days.
- Alerts tested, noise silenced, escalation path confirmed with a live test.
- Runbook links checked, access verified for at least two people.
- On-call rota published with names, hours and a fallback contact.
- One place where anyone can see what shipped this week.
Then close the laptop. The point of the preparation is not to prove how careful you are; it is to make sure a quiet fortnight stays quiet, and that anyone who does get paged can fix the problem in ten minutes without ringing a colleague on a beach.
Photo: Andrea Piacquadio / Pexels
