Friday Is Not the Problem
How a sensible-sounding rule keeps teams from fixing what is actually broken
The phrase “don’t deploy on Friday” has become one of those pieces of engineering wisdom that people repeat without much examination. It sounds sensible. It feels responsible. And it is almost entirely wrong.
I recently read a post defending this rule. It was well-written and made several arguments that, on the surface, seem reasonable. But each of these arguments, when examined closely, reveals a deeper problem that the Friday rule does not solve but merely hides.
Let me address them one by one.
“You rarely have full control over everything involved in a deployment”
The argument goes like this: infrastructure, third-party services, configuration differences, traffic patterns, and environment-specific behaviour can all surface issues only after a change is actually applied. These are not always predictable in staging or test environments.
This is true. It is also completely irrelevant to the question of which day you deploy.
If your production environment behaves differently from staging in ways that cause incidents, that is a problem on Tuesday just as much as on Friday. The unpredictability does not magically disappear because you have five working days ahead of you. What changes is your ability to throw human hours at the problem.
The correct response to environmental unpredictability is not to limit your deployment days. It is to invest in observability, automated rollbacks, and production testing strategies like canary deployments and feature flags. These approaches reduce blast radius and enable fast recovery regardless of when something goes wrong.
If your only mitigation strategy for environmental surprises is “have people available to fix things manually”, you have not solved the problem. You have just accepted it.
“Data migrations are fundamentally different and risky”
The post argues that changes touching real data can be slow, irreversible, dependent on data volume and shape, and risky to roll back. Treating them the same as a small code deploy ignores real operational complexity.
I completely agree. Data migrations are different and require special handling.
But this is an argument for treating data migrations differently. It is not an argument for a blanket rule about which days any deployment can happen.
A well-designed migration strategy includes expand-and-contract patterns, backward-compatible schema changes, and the ability to run migrations independently from code deployments. If your migrations are so risky that they require days of potential cleanup time, the problem is not Friday. The problem is how you are doing migrations.
Conflating “don’t deploy risky migrations on Friday” with “don’t deploy anything on Friday” is sloppy thinking. It takes a legitimate concern about one specific type of change and inflates it into a universal policy that restricts all changes. This is how reasonable caution turns into irrational fear.
“Limited availability of teammates and reduced support coverage”
This is perhaps the most honest of the arguments, and it deserves a direct response.
The concern is that releasing late on a Friday means fewer people are available if something goes wrong. Response times will be slower. The on-call engineer might be alone.
But notice what this argument assumes: deployments are expected to cause problems that require human intervention. This assumption is so deeply embedded that it passes without comment. It is treated as a law of nature.
It is not. It is a symptom of an immature deployment process.
When deployment is a non-event, when changes are small, well-tested, and automatically rolled back if metrics degrade, you do not need a war room on standby. The system handles problems faster than humans could anyway.
The fear of reduced weekend coverage only makes sense if you expect to need that coverage. And if you expect to need it, that expectation should be treated as a problem to solve, not a constraint to work around.
“Mature engineering teams optimise for reliability, not bravado”
This framing is clever but misleading. It positions Friday deployments as reckless showmanship and the Friday rule as careful professionalism.
The reality is the opposite.
Truly mature teams do not need deployment windows because they have invested in making deployment boring. They deploy dozens of times per day. Each individual deployment is so small and so well-tested that it carries almost no risk. They can deploy on Friday afternoon and go home without anxiety because they have built the systems and practices that make this possible.
Avoiding Friday deployments is not a sign of maturity. It is a sign that you have accepted an immature deployment process as permanent.
The most reliable teams I have worked with never talked about which days were safe to deploy. The question simply did not arise. Deployment was like committing code or running tests: something you do continuously, without ceremony, because your systems are designed to handle it safely.
“Consider blast radius, rollback strategies, observability, and on-call load”
Absolutely. Consider all of these things. But consider them as engineering problems to solve, not as reasons to restrict when you can ship.
Blast radius should be limited by deploying incrementally, using feature flags, and rolling out to small percentages of traffic before going wide. Rollback should be automated and triggered by metric degradation, not by a human noticing a problem and deciding to act. Observability should be good enough that problems are detected in seconds, not hours. On-call load should be reduced by building systems that recover automatically.
If you have all of these things in place, Friday is just another day. If you do not have them in place, the Friday rule is a bandage over a wound that will keep bleeding every other day of the week.
“Good software engineering is about making smart trade-offs”
I agree completely. But the smart trade-off is not between deploying on Friday and waiting until Monday.
The smart trade-off is between maintaining a dysfunctional deployment process and investing in one that actually works. One of these trade-offs solves the problem. The other just delays it until after the weekend.
The expanding forbidden zone
There is a pattern I have seen repeatedly in teams that adopt the Friday rule. First it is “don’t deploy on Friday”. Then it becomes “don’t deploy on Friday afternoon”. Then “don’t deploy after Thursday lunch, just to be safe”. Then “don’t deploy the day before a bank holiday”. Then “don’t deploy during the Christmas period”, which somehow stretches from early December to mid-January.
The forbidden zone keeps expanding because the underlying problem remains unaddressed. You have not made deployments safer. You have just reduced the number of days when you are willing to confront how unsafe they are.
The rule as technical debt
Here is the uncomfortable truth: the “don’t deploy on Friday” rule is a form of technical debt.
Every time you follow it, you reinforce the idea that deployments are inherently dangerous. You avoid the feedback that would push you to improve. You normalise a dysfunctional process instead of fixing it. The rule does not make you safer. It makes you complacent.
If your deployments are scary, the solution is not to do them less often. It is to do them more often, in smaller increments, with better automation, faster feedback, and reliable rollback. The fear you feel about Friday deployments should be treated as a signal, not as wisdom to be enshrined in team policy.
This is an invitation, not a challenge
I want to be clear about what I am not saying. I am not saying “drop everything and push to prod this Friday”. Those of us who encourage Friday deployments are not doing it to be provocative or to score points.
We do it because we have seen what it looks like when teams feel safe enough to do it. We have lived through the pain of not being able to. And we have seen the benefits of moving past that fear.
I am aware of how many invisible blockers stand in the way. Fear of being blamed if something goes wrong. A belief that “this is just how we do things”. Lack of confidence in the release process. Unclear ownership. The absence of good tooling and observability. These are real obstacles, and dismissing them as excuses would be unfair.
But accepting the Friday rule means accepting these blockers as permanent. It means letting fear drive your decisions and treating the status quo as inevitable.
Where the real work begins
So no, you do not need to deploy this Friday. But imagine a world where you could, and it was not a big deal.
Then ask yourself: what would need to be true for that to happen? What stands in the way?
That question is where the real work begins. And answering it honestly will do far more for your reliability than any rule about which days are safe to ship.