Anyone who's worked on a dev team knows this conversation. It usually happens at the worst possible time, like 5:50pm on a Friday, when someone asks in Slack "so are we merging this or does it wait until Monday?" and the channel goes quiet for thirty seconds before the usual argument kicks off. I've seen this play out at three different companies and never once seen anyone walk away fully convinced the other person was wrong. That's kind of the whole problem. No dogma survives contact with reality here. The case against Friday deploys really comes down to who ends up paying the bill if something breaks. You think the deploy is clean, tested, reviewed — and something still slips through, because it always does eventually. If that happens on a Thursday at 10am, you've got the whole team awake, the author of the code still has the context fresh in their head, and you probably fix it in twenty minutes without anyone outside the company noticing. If it happens on a Friday at 6pm, the whole picture changes: the person who shipped it is already thinking about dinner, support is skeleton-crew or nonexistent, and the stakeholder who was supposed to validate the feature only sees the problem Monday morning, after customers have been complaining since Saturday. It's not that the bug is more likely on a Friday. It's that the cost of fixing that same bug goes up disproportionately when nobody's around to help. Except there's a counterargument that's honestly stronger than it looks at first, and it's this: banning Friday deploys doesn't eliminate risk, it just pushes it. Everything that would've shipped Thursday or Friday piles up and goes out all at once the following Monday, in one bigger deploy with more changes bundled together, which statistically increases — not decreases — the odds of something breaking. And when it does break, it's harder to figure out which of the ten changes was the culprit. Teams with mature CI/CD pipelines, automated tests that actually cover the cases that matter, and fast rollback systems tend to argue this: banning Friday deploys treats the symptom, which is fear of deploying, and ignores the cause, which is a lack of trust in the process itself. And this is where the whole debate actually gets resolved, or at least where it should get resolved, if people stopped arguing about courage and discipline and started talking about something a lot more concrete: how long it takes to roll back a bad deploy. This changes everything. If your team can roll back in minutes, with a button or a single command, Friday stops being a problem — it's just another day. If reverting means opening a new pull request, waiting on CI, getting someone else's approval, and deploying manually all over again, then yeah, shipping at 4pm on a Friday is Russian roulette, and in that case "never on Fridays" isn't overcaution, it's just common sense. Teams like Netflix or Google, which do real continuous deployment multiple times a day, barely have this conversation internally anymore — because the nightmare scenario that fuels the debate, "what if it breaks and nobody's around to fix it," has essentially stopped existing in their process. The problem got solved at the root, not dodged by calendar. Team size matters a lot here too. At a three or four person startup where everyone's reachable pretty much always, even on weekends, banning Friday deploys is a somewhat artificial rule — nobody's going to be left alone firefighting, because everyone's around anyway. At a two-hundred-engineer company with staggered support shifts and an enterprise client who'll call furious if the product goes down, that same rule stops being bureaucracy and becomes genuine protection. Worth saying clearly: there's no universal answer here, and anyone trying to force one without looking at the team's actual context is solving the wrong problem. One thing worth paying attention to, rarely said out loud, is that "never deploy on Friday" tends to calcify into dogma nobody questions anymore. And that's when something perverse happens: the rule becomes an excuse not to invest in better testing, observability, automated rollback — because, well, "we don't deploy that day anyway, why bother." That's the worst of both worlds. You keep the fragile process and you still lose a full day of shipping cadence every single week. At the end of the day, this splits teams into two kinds. There are the ones that trust their own pipeline enough to treat Friday like any other day, and the ones that don't trust it but would rather pretend the problem is the calendar. Which one is yours?