Deploying on Friday: a risk framework, not a superstition
'Never deploy on Friday' is a slogan. What you actually need is reversibility, monitoring, and an honest blast radius.
By Nzubechukwu Cyprian · Pharmacy student at UNN, full-stack developer
Every developer hears "never deploy on Friday." It's decent folk wisdom, but it's a superstition standing in for a missing framework. What Friday actually signals is: you're about to leave the code unwatched. The real question isn't when — it's how bad is it if this goes wrong while nobody's looking.
The three questions I ask before any deploy
Can I undo it in one command? If a deploy is a git revert away from safety, its worst case is minutes. If rollback means archaeology, its worst case is a weekend. Reversibility decides more than the calendar.
What's the blast radius? A copy change and a database migration do not belong in the same risk category. I sort every change into: cosmetic, behavioural, data-touching. Data-touching changes get backups, dry runs, and daylight hours — regardless of the day.
Will anyone be watching? If I'm around for the next hour, a Friday afternoon deploy is fine. If the next pair of eyes is Monday, the deploy waits — not because Friday is cursed, but because silence is.
The honest version of the slogan
Deploy small, deploy reversible, deploy watched. Do all three and Friday is just a day. Skip them and Tuesday will burn you anyway.
Keep reading
- Software engineering
Naming things is the whole job, sometimes
Most codebases don't have a naming problem — they have a thinking problem that shows up in their identifiers.
- Software engineering
Your README is your first interview
Before anyone judges your code, they judge your README. What a good one actually contains, from someone who reads a lot of them.
- Software engineering
The bug that taught me to read error messages properly
A three-line error sat in my logs for a week. It told me exactly what was wrong. I just never read past the first line.