"No deploys on Friday" was a rule on our team for years. It sounds responsible. It's actually a confession: it means your deploys are risky enough that you need a two-day buffer of people at their desks to catch the fallout. The rule doesn't make deploys safe. It just concentrates the risk into Monday through Thursday and makes releases feel like events.
I wanted to kill the fear instead of scheduling around it. Fear of deploying is almost always fear of two things: you can't tell quickly if a release is bad, and you can't get back to safe quickly when it is. Fix both and the day of the week stops mattering.
First, small releases. When you deploy once a week, that release contains fifty changes, and when something breaks you're bisecting fifty suspects under pressure. When you deploy ten times a day, each release is a handful of changes and the culprit is usually obvious. Small batches aren't just faster — they're the single biggest lever on how scary a rollback is.
Second, a rollback that's boring. We made "go back to the previous version" a one-command, fully automated operation that anyone on-call could run without thinking. No rebuilding, no manual database gymnastics, no paging the one person who knows how. If rollback is easy, going forward is cheap, because a mistake costs you sixty seconds instead of an evening.
Third, we wired the deploy to watch itself. After a release, automation stares at error rate and latency for a few minutes and rolls back automatically if they cross a threshold. The machine reacts faster than a human reading a dashboard, and it doesn't get tired or optimistic.
Once those three were real, "no Friday deploys" quietly stopped making sense. We deleted the rule. Nothing bad happened, because the thing that made Fridays scary — big, slow, hard-to-undo releases — was gone.
The goal was never to deploy on Fridays for its own sake. It was to build a release process so unremarkable that the calendar became irrelevant. If you're afraid to ship on Friday, the day isn't the problem. Your release process is telling you something, and it's worth listening.
– Sergey Shinder
