The first time a deploy pages the whole team at midnight, someone invents maintenance windows. The tenth time, someone leaves a window open for three days "just in case." That is how you train people to treat red as negotiable.
What a maintenance window is for
You are about to break or bounce something on purpose — migrate a database, cut DNS, reboot a fleet, run a risky migration. Checks will fail. Those failures are not incidents. A window tells the monitor: record if you want, but do not page, and do not count this against uptime the way a surprise outage would.
Customers may still deserve a status update. Silence inside the tool is not the same as silence outside.
Rules that keep windows from rotting the culture
Time-box hard. Start and end. If the work overruns, extend deliberately — do not shrug into an endless mute.
Scope the monitors. Window the checkout migration, not every URL you own. A wide window is how a real outage on an unrelated service stays quiet.
Announce when users will feel it. Put the window on the status page if customers will see errors or freezes. Internal-only blips can stay internal.
Prefer change windows over "quiet mode forever." If production cannot survive a deploy without muting alerts for hours, the deploy process is the incident.
Never use windows to hide a flaky monitor. Fix confirmation logic or the check itself. A permanent soft-mute is how you miss the night it is real.
A simple pre-deploy checklist
- Which monitors will go red on purpose?
- How long should that be allowed?
- Who is awake if it goes sideways after the window ends?
- What will customers see, and is the status page ready?
- Who closes or extends the window?
If you cannot answer those, you are not ready to suppress pages.
Afterward
When the window ends, glance at the monitors. Green should mean green, not "still deploying." If you need a second short window, take it. If the same window appears every release, put the pain in the release playbook — not in a culture where alerts are optional.
