Practice6 min read
The Friday deploy checklist
Seven questions we ask before any release goes out late in the week, and why most of them have nothing to do with code.
"Never deploy on a Friday" is good advice for a team without guardrails. For everyone else it is a tax: features wait three days, branches drift, and Monday becomes the riskiest day of the week because everything ships at once.
We deploy on Fridays. Usually a dozen times. What we do not do is deploy without asking a few questions first. This is the list, more or less as it lives in our runbook.
1. Can this release roll back on its own?
If the answer is "only by shipping a revert", it is not ready for a late-week window. Every service that ships on Friday has to have automatic rollback configured, with at least one guardrail that can trigger it.
2. Is there a schema change hiding in it?
Rollbacks move traffic, not data. A migration that drops a column cannot be rolled back by shifting traffic to the previous version, because the previous version expects the column to exist. We split these into two releases: expand first, contract a week later.
3. Who is on call, and do they know it is going out?
Not "is someone on call". Do they know this release exists, what it touches, and where the flag lives? A two-line message in the on-call channel costs nothing:
v2.14.0 checkout-service, starts 14:02
new tax engine behind tax-engine-v2, 25% EU only
rollback: automatic on error rate > 0.5%
4. Is the blast radius small at first?
The first stage should be small enough that a total failure is a bad graph, not an incident. For most of our services that means 1% of traffic, or a single internal tenant.
5. Are the guardrails watching the right thing?
Error rate catches crashes. It does not catch a checkout button that renders but does nothing. For anything near revenue we add one business metric, like conversion or orders per minute, compared against the baseline version.
6. Does the stage hold long enough to see a weekend pattern?
Friday afternoon traffic is not Saturday morning traffic. For releases that touch scheduling, batch jobs or anything time-based, we let the 25% stage hold overnight before promoting.
7. Would you be comfortable reading the audit log out loud?
This one is half a joke. If the release history reads like "promoted manually, skipped stage, overrode guardrail", the process is the problem, not the day of the week.
None of this is clever. It is the boring part of shipping, written down so nobody has to remember it at 4:45 PM. That is the point: make the release boring, and the day stops mattering.