Stop deploying on Fridays (but actually)

“Don’t deploy on Friday” is one of those rules everyone repeats and nobody interrogates. It sounds wise. It probably even helps. But it hides the actual rule, and because it hides it, it fails in specific, predictable ways.

The real rule is this: do not deploy when the only person who can fix what might break is about to be unavailable for hours.

Sometimes that person is offline on Friday evening. Sometimes they are offline on Tuesday at 17:00 because they have a dentist appointment. Sometimes they are offline on Monday morning because they are driving. The day of the week is a proxy. It is a useful proxy, but treating the proxy as the rule leads to deploys you should not be doing on Tuesdays, and blocks deploys that were fine to do on Fridays.

I have shipped deploys at 18:00 on a Friday and gone out for dinner immediately after, with zero regret, because the change was reversible in ten seconds and I was reachable for the next four hours. I have also refused to deploy at 10:00 on a Tuesday because the lead engineer on that feature was flying to Lisbon in ninety minutes and her laptop was closed.

The two variables

There are only two things that matter when deciding whether now is a reasonable moment to deploy.

One, how bad would it be if this deploy broke something. A new feature with no migrations, a small content change, a typo fix — the downside is small and quickly reversible. A schema migration, an auth change, a payments flow update — the downside is large and possibly not instantly reversible.

Two, how available are the people who understand this change. If the only person who wrote this code is about to be offline for eight hours, your ability to debug a broken version of it for eight hours is zero.

Multiply those together and you get a rough answer.

Why Friday became the rule

Friday became the proxy because for most teams, most of the time, the combination that matches “high downside, low availability” happens to fall on Friday evening. Features that ship that week tend to be on Fridays. Weekends mean lower monitoring, slower response, fewer people in chat. The deploy and the offline window line up.

But the underlying rule is about the alignment, not about the day. If your team is distributed across time zones and Friday in Amsterdam is Thursday in San Francisco, the rule changes meaning. If your team has mandatory office hours on Friday and everyone is at the desk until 18:00, Friday might actually be a fine time to deploy. If your team does async work and nobody is guaranteed to be around on any specific day, every day is potentially Friday.

I have been on teams where the cultural “no Fridays” rule was treated with religious seriousness, and the team would then push a big release at 16:00 Thursday, which functionally was “deploy and immediately stop watching it” because half the team was leaving at 17:00 that day. The rule was followed, the spirit was not.

What I actually ask before deploying

Not “what day is it.” Three questions.

How long would it take me to roll this back if it broke. If the answer is less than two minutes and I trust the rollback, this deploy is low-risk regardless of when it is.

Who needs to be reachable if it breaks, and are they reachable. Not “theoretically on call” — actually reachable. If the answer is “me alone and I’m about to be driving,” the deploy waits.

Is there a clear signal I would see if it broke. Not “we would notice eventually.” Something that would reach someone within five minutes of going wrong. If the answer is no, the deploy waits until I can watch it myself for thirty minutes.

Those three questions have nothing to do with the calendar.

The feature-flag loophole

The reason many teams can deploy on any day is that they are not actually deploying the feature when they merge the code. They are deploying dormant code behind a flag that is off. The feature turns on later, in a separate action, during business hours.

This is a legitimate way to decouple the “when code hits production” question from the “when users see the change” question. The code deploy is boring because it changes nothing visible. The feature turn-on is a small reversible action.

It does not, however, actually remove risk from the deploy. The code being there, even inactive, can break things — bad imports, startup errors, migrations that ran regardless of the flag. The flag moves some of the risk, not all of it.

So the Friday rule does not disappear because you have feature flags. It changes shape. The code deploy stays honest about its risk. The feature turn-on is a new kind of deploy with its own timing question.

The honest version

I deploy on Fridays when the change is small, my phone is charged, and I have no plans for the next few hours. I do not deploy on Tuesdays when the change is big and the person who wrote it is about to fly. I do not deploy at all when nobody who understands the code is available.

The rule is about alignment, not about the day. Calling it “don’t deploy on Fridays” loses the actual signal in exchange for a rule that is easier to say.