Every Friday, the same ritual plays out in engineering Slacks worldwide: "No deploys on Friday." Someone even made a website about it. There are memes. T-shirts. It's become an unquestioned commandment of software engineering.
And it's a massive red flag about your engineering org.
The Real Problem Isn't Friday
Think about what "no Friday deploys" actually means. It means your team doesn't trust its own deployment pipeline enough to ship code when there's a weekend ahead. Unpack that for a second.
You're telling me that your CI/CD pipeline, your test suite, your staging environment, your monitoring, your rollback strategy — all of that infrastructure you spent months building — can't be trusted unless a full engineering team is standing by on a weekday? That's not a calendar problem. That's an engineering problem.
Teams that ban Friday deploys aren't being cautious. They're admitting defeat.
What "No Friday Deploys" Actually Tells You
It tells you at least one of these things is true:
- Your tests don't catch real issues. If your test suite gave you actual confidence, you wouldn't care what day it is. You'd deploy, watch the metrics, and go home.
- Your rollbacks are manual or scary. If rolling back a bad deploy takes more than 60 seconds and zero human judgment, your deployment infrastructure is incomplete.
- Your monitoring doesn't alert fast enough. If it takes a human staring at dashboards to catch a regression, you've got an observability gap.
- Your deploys are too big. If a single deploy carries so much change that it's genuinely risky, you're not deploying often enough. Small, frequent deploys are inherently safer.
Every one of these is fixable. And fixing them makes every day safer, not just Monday through Thursday.
The Companies That Deploy on Friday (And Weekend, And 3 AM)
Netflix deploys continuously. So does Google. Amazon ships code every 11.7 seconds on average. These aren't reckless companies — they're companies that invested in making deployment boring.
Feature flags. Canary releases. Automated rollback triggers. Progressive rollouts. Blue-green deployments. These aren't fancy nice-to-haves. They're the bare minimum for treating deployment as the non-event it should be.
When you have these in place, the day of the week becomes completely irrelevant. Your deploy at 4 PM Friday is exactly as safe as your deploy at 10 AM Tuesday. If it's not, fix the pipeline, not the calendar.
"But What About On-Call?"
This is the one semi-legitimate argument. If your on-call rotation is thin over weekends, maybe don't introduce unnecessary risk. Fair.
But here's the thing: production issues don't wait for business hours anyway. If your service can break on a Friday deploy, it can also break from a Thursday deploy that manifests Saturday. Or from a traffic spike. Or from a dependency going down. Or from a certificate expiring.
If your weekend on-call can't handle incidents, that's an on-call problem. Fix it by having proper runbooks, automated remediation, and adequate staffing. Not by pretending Friday doesn't exist.
The Culture Cost
Here's what really bothers me about the Friday deploy ban: it creates a culture of fear around shipping. And that fear compounds.
First it's "no Friday deploys." Then it becomes "don't deploy after 3 PM Thursday either, just to be safe." Then it's "let's batch everything into Tuesday morning deployments." Before you know it, you're doing weekly releases, your PRs are massive, merge conflicts are constant, and every deploy is genuinely terrifying — because you made it that way.
The safest deployment culture is one where deploying is so routine, so boring, so utterly unremarkable that nobody even thinks about what day it is.
What To Do Instead
Instead of banning Friday deploys, invest in:
- Automated rollbacks — if error rates spike, roll back without human intervention
- Feature flags — decouple deployment from release so you can ship code without activating it
- Canary deployments — route 1% of traffic to the new version first
- Comprehensive monitoring — alerts that fire within minutes, not hours
- Small, frequent deploys — the smaller the change, the easier to debug
Do these things, and Friday deploys become a non-issue. Skip them, and no amount of calendar restrictions will save you.
Ship It
The best engineering teams I've worked with deploy on Fridays, Saturdays, holidays, and at 2 AM. Not because they're reckless, but because they've made it safe to do so.
If you can't deploy on Friday, don't ban Friday deploys. Fix the reason you can't.
Your calendar isn't a deployment strategy.
Top comments (0)