No deploys on Friday: wise rule or a sign your monitoring is broken?

Every few months, the "don't deploy on Friday" debate flares up again.

One side says: obviously. Nobody wants to debug production at 7pm on a Friday, and weekend on-call is miserable.

The other side says: if you're afraid to deploy on Friday, you're afraid to deploy, full stop. Fix that instead.

I think both sides are right about different things, and the real question is hiding underneath: how quickly would you know if a deploy broke something? Let's dig in. I'd love to hear where you land.

The case for the freeze

Fewer people around. If something breaks at 5pm Friday, the people who know the system best may be offline until Monday.
Customer impact can be bigger. For many businesses, a weekend outage goes unnoticed internally for longer, while customers keep hitting it.
Humans are tired. End-of-week changes get less careful review. That's not a moral failing. It's just true.
Some failures are slow. A memory leak, a full disk, a cron job that runs on Saturday. A deploy that looks fine at 4pm can fail at 2am.

The case against

It hides the real problem. If deploys are risky on Friday, they're risky on Tuesday too. You've just chosen a better day to be surprised.
It creates a Thursday crunch. Everyone rushes to ship before the freeze, which concentrates risk instead of reducing it.
Small, frequent deploys are safer. A freeze encourages bigger batches on Monday, which are harder to debug.
Fixes need to ship too. A rule that blocks a security patch on Friday is a bad rule.

What I think actually matters

The debate is mostly about detection time and rollback time.

If a broken deploy is detected within two minutes and rolled back within five, Friday is much like any other day. If a broken deploy is detected when a customer emails on Saturday, no day is safe, Friday is just the worst.

So instead of arguing about the calendar, measure those two numbers.

A post-deploy check you can add today

Here's a simple script to run right after a deploy. It hits a few important URLs repeatedly for a few minutes and fails loudly if anything looks wrong:

#!/usr/bin/env bash # post-deploy-check.sh — run after deploy; non-zero exit = roll back set -euo pipefail URLS=( "https://example.com/" "https://example.com/login" "https://example.com/api/health" "https://example.com/pricing" ) DURATION=300 # seconds to keep checking INTERVAL=15 MAX_MS=2000 end=$(( $(date +%s) + DURATION )) while [ "$(date +%s)" -lt "$end" ]; do for url in "${URLS[@]}"; do out=$(curl -s -o /dev/null -w "%{http_code} %{time_total}" --max-time 10 "$url" || echo "000 10") code=${out%% *} ms=$(awk -v t="${out##* }" 'BEGIN { printf "%d", t * 1000 }') if [ "$code" -ge 400 ] || [ "$code" = "000" ]; then echo "FAIL $url -> $code"; exit 1 fi if [ "$ms" -gt "$MAX_MS" ]; then echo "SLOW $url -> ${ms}ms"; exit 1 fi done sleep "$INTERVAL" done echo "post-deploy check passed"

Wire it into your pipeline:

# example CI step - name: Post-deploy check run: ./post-deploy-check.sh - name: Roll back on failure if: failure() run: ./rollback.sh

It's not sophisticated. It doesn't need to be. It catches the most common "deploy went out and the site is returning errors" failure in minutes, not hours.

The slow failures need something else

A five-minute post-deploy check won't catch the memory leak that takes six hours, or the scheduled job that runs on Sunday. For those, you need monitoring that keeps running all weekend, with alerts that reach a human:

External checks on the pages and APIs customers use (an uptime monitor like upordown.online or your own scripts on a schedule).
Resource alerts (memory, disk) with enough warning to act.
A clear on-call owner, even if it's "whoever deployed checks their phone on Saturday morning".

Measure your own numbers first

Before changing any rule, look at the last ten incidents caused by deploys (or the last ten deploys, if you're lucky enough not to have incidents). For each, write down:

When it was deployed.
When someone noticed the problem, and how (alert, colleague, customer).
When it was fixed or rolled back.

If most problems were noticed by customers hours later, your issue isn't Friday. It's detection. If problems were noticed in minutes but rollbacks took an hour, your issue is the rollback process. Either way, you now have something specific to fix, and the Friday debate becomes much less emotional.

A middle ground many teams use

Small, low-risk changes: ship any day, with automated post-deploy checks.
Big or risky changes (migrations, infrastructure, payment flows): prefer early in the week, when the team is around to watch.
Fixes: always allowed.
Whoever ships on Friday afternoon stays reachable for a few hours afterwards.

That's not a freeze. It's matching risk to the people available to handle it.

Questions for you

Does your team have a Friday rule? Written or unwritten?
How long does it take you to notice a bad deploy today, honestly?
Has a Friday deploy ever ruined your weekend? Or has a freeze ever made things worse?