Planning maintenance windows around your traffic

Pick the window from your own access logs, not from a clock. "Do it at 3am" is an office habit, and it is wrong often enough to matter: an estate aimed at one country can be dead quiet at 4pm local and busy at 2am.

Find the real trough before you book anything

Take four weeks of raw logs, not an analytics dashboard. Analytics drops bots, blocked visitors and anyone who leaves before the script fires, and during maintenance those are exactly the requests that matter. Count hits per hour of the week, so you get 168 buckets rather than 24: Sunday 09:00 and Wednesday 09:00 are rarely the same site.

awk '{print $4}' access_log | cut -d: -f2 | sort | uniq -c | sort -rn

Read it against three things:

• Human sessions. The obvious number, and the one most people stop at.
• Crawler activity. Search engine fetches follow their own rhythm and often peak while your visitors sleep. A window that is quiet for people can be your busiest crawl hour.
• Scheduled jobs. Backups, feed imports and certificate renewals cluster around 02:00-04:00. Colliding with your own backup is a common self-inflicted outage.

Worked example: trough 05:00-07:00 UTC, nightly backup at 05:30, so the usable window is 06:15-07:00. The work fits in 45 minutes or moves to the second-best trough.

When there is no shared quiet hour

An estate split across regions has no single trough. Two sites peaking twelve hours apart mean any window is prime time for one of them. Do not average them into a compromise hour that suits nobody.

It is also a quiet argument for keeping regional audiences on regional footprints, US or EU: separate footprints can be maintained on separate schedules.

Nobody watching also means nobody notices

What makes a quiet window feel safe is what makes it dangerous. At the trough, a broken cart, a failed redirect or a certificate that did not reload produces almost no complaints, so the first report arrives hours later when volume returns and the cause has gone cold.

Never let the window end when the work ends. Budget an equal block afterwards for checks you run yourself: load a real page uncached, follow one redirect chain end to end, submit one form, look for a rise in 5xx responses, confirm the certificate serves its full chain. If you cannot stay awake for that, the hour is wrong.

Stagger rather than doing everything at once

Taking twenty sites down together turns a routine change into one event with one blast radius. Stagger instead: one site, verify, then three, verify, then the rest. It costs a few evenings and buys you a fault that stops at site one. Start where a loss hurts least, and never test on the flagship.

When it cannot wait

Security patches, expiring certificates and active abuse do not negotiate. Apply them now and shrink the exposure:

1. Change one thing only, so any regression has an unambiguous cause.
2. Write the rollback step down before executing the change.
3. Still do one site first, unless something is being actively exploited.
4. If a site must go offline for more than a couple of minutes, serve a real 503 with a Retry-After header rather than a broken page or a redirect home, which is what Google advises for a temporary pause.

Telling people without over-promising

Announce a date and a maximum duration, never a precise finish time. "Between 06:00 and 07:00 UTC on Tuesday, up to 45 minutes of intermittent errors" survives contact with reality; "back by 06:20" does not. Say what may break instead of promising nothing will. Notify affiliates and API consumers separately; they need lead time, visitors only need a banner. If you overrun, post an update at the promised end time even with nothing new, because silence turns a delay into an incident. Slot recurring windows into the wider routine in running your estate.