We don’t deploy on Fridays. That’s not a suggestion. It’s policy.
Not because we’re superstitious. Because we only work Monday to Friday, our applications run 24/7, and support is only available during business hours. Deploying on a Friday creates a weekend of risk that nobody is around to manage.
It’s one of those rules that sounds obvious once you say it out loud, but took a real incident to formalise.
Every team I’ve worked with has some version of this. Rules that aren’t in the runbook. Rituals that nobody would put in a pull request description but everyone follows.
Don’t deploy after 3pm. Don’t deploy before standup. Don’t deploy when the one person who understands the staging environment is on holiday.
These aren’t best practices. They’re survival mechanisms dressed up as process.
The no-Friday rule is the obvious one. But there are others.
We always do a quick sanity check in the team channel before pushing to production. Not a formal sign-off, just a “heads up, deploying the thing” message. Nobody mandated it. It just became the norm after someone deployed during a demo once.
There’s also an unspoken preference for deploying early in the week. Monday or Tuesday. It gives you the rest of the week to monitor, catch edge cases, and fix anything before the quiet of the weekend.
None of this is written down anywhere. If you asked us for our deployment policy, you’d get a document about CI pipelines and release tags. The real policy lives in Slack messages and team habits.
Deploy rituals are almost always born from something going wrong. Nobody invents a rule about Friday deployments because they sat down and thought about risk management. They invent it because something broke on a Friday evening and they spent their Saturday fixing it.
Rituals are scar tissue. They’re the team’s immune system responding to past infections.
And they work. Not because they’re scientifically rigorous, but because they create friction in the right places. A two-second Slack message before deploying isn’t process overhead. It’s a circuit breaker.
The best deploy rituals are the ones teams would never put in their documentation.
The developer who always checks the monitoring dashboard three times. The one who waits exactly ten minutes after deploying before closing the terminal, just in case. The lead who sends a thumbs-up emoji in the channel as an unofficial “all clear.”
None of it is rational. All of it is earned.
The best processes aren’t always the ones you can explain in a retrospective. Sometimes they’re just the quiet habits that keep things from falling over.