Friday deployments have a reputation problem, and most of it is earned. But the day is rarely the real issue. What causes trouble is the assumption that once the code is written and the tests pass, the rest of the job is done.
A Friday release ships into a period when fewer people are at their desks, when the engineer who built the change may be away from a laptop, and when a small fault can sit undetected until Monday. None of that is fatal, but all of it needs planning. Here are twelve checks worth confirming before you deploy.
Rollback before rollout
Every deployment needs two plans: how to get the change in, and how to get it out. Most teams are confident about the first and vague about the second.
The rollback plan has to be specific. Not "we'll revert the deploy" but: which commit or artifact we return to, who has permission to trigger it, and how long it takes. If the honest answer is "about twenty minutes, assuming the build cache is warm", write that down, because the number shapes how long you watch a dashboard before you act.
Feature flags make this far easier. If the risky part of the change sits behind a flag, turning it off is a rollback measured in seconds that touches no data. Where flags are not practical, agree the threshold that triggers a rollback in advance: error rate above a set level for five minutes, queue depth climbing, checkout completions falling.
Put all of it somewhere the on-call engineer can find at 2am. Not in the head of the person who wrote the code.
Database migrations
Migrations are the part of a deployment that rollback plans forget. Code reverts in seconds. A dropped column does not.
The expand and contract pattern
Ship schema changes in stages rather than all at once:
- Expand. Add the new column or table, keeping the old structure intact so existing code still works.
- Backfill. Copy data across in small batches, rate-limited and resumable if it fails halfway.
- Switch. Move reads and writes to the new structure, ideally behind a flag.
- Contract. Remove the old column once nothing reads it and you are certain you will not need to roll back.
Watch for locking. An ALTER TABLE that rewrites a large table can hold locks long enough to take a site down, so test the migration against a production-sized copy first and set a statement timeout. Keep schema changes and the code that depends on them in separate deploys wherever possible.
Monitoring and alerts
Deploying into a system you cannot see is a gamble. Before you ship, check that you have:
- A dashboard open with the signals that matter — request rate, error rate, latency, saturation, plus one business metric such as orders per minute.
- Alerts that reach a human, not just a channel. Send a test to confirm the route works.
- A recorded baseline: note the numbers before the deploy so you can compare like with like.
- Synthetic checks on the critical journeys, running from outside your own network.
- Log levels turned down. Debug logging left on can flood your pipeline and your budget.
Context matters when you interpret the results. A ten per cent error rate means something different at 3am than it does during the lunchtime peak.
On-call handover
Who owns this at 19:00? If the person who wrote the change has finished for the week and is on their way to a wedding, whoever is covering needs to know that.
A good Friday handover covers four things in plain language: what changed, what to look for, what to do first if it goes wrong, and who to wake up. It takes ten minutes and can save a weekend. Don't hand over a risky deploy and a first pager shift at the same time; pair a new on-call engineer with someone experienced. Give escalation paths real phone numbers rather than a Slack handle that might go unread.
If the change is genuinely risky, keep one engineer reachable — not working, just reachable — until the system has stayed stable through a peak period.
Scope, comms and freeze windows
Ask what else is going in. Two teams shipping to the same service on the same afternoon makes diagnosis harder, and when both changes are described as small, that is usually where the interesting outages come from.
Then tell people. Support should know what changed and what a customer might notice. Decide who updates the status page. If you are changing an API, give integrators warning. And respect existing freeze windows: many organisations have periods, such as peak trading or quarter end, where deploys need sign-off. Friday afternoon is not the moment to discover that yours does.
The twelve checks
- The change is reviewed, merged, and built from a tagged artifact you can identify later.
- The rollback is documented, permitted, and timed.
- Risky behaviour sits behind a flag you can switch off without a deploy.
- Migrations are backwards compatible and separated from the code that uses them.
- Backfills are batched, rate-limited, and resumable.
- A dashboard is open and the pre-deploy baseline is recorded.
- Alerts reach someone who is actually on call.
- Synthetic checks cover the critical user journeys.
- One named person owns the system until Monday, with phone numbers for escalation.
- Support and other customer-facing teams know what is shipping.
- No other significant change is landing on the same service at the same time.
- You have agreed the time at which you will stop watching and either keep it or roll back.
Saying not today
Run the list. If two or three items are unresolved and the change is not urgent, the cheapest decision is to wait until Monday morning.
That is not timidity. A Monday deploy happens when everyone is fresh, the whole team is at their desks, and a problem that appears at 10:00 is usually fixed by 11:00. The same change shipped at 16:30 on a Friday, with no rollback plan and half the team gone, leaves you far less room to fix anything.
If it truly cannot wait — a security fix, a broken payment flow, a contractual deadline — then ship it deliberately. Smallest possible change, behind a flag if you can manage it, with someone watching and a plan for the weekend. Friday is not the problem. Being unprepared is.
Photo: RDNE Stock project / Pexels
