Maintenance window policy: rules for the hours when change is allowed

A maintenance window is where scheduled risk is supposed to live — the hours when it is legal to break something on purpose. At small teams it usually decays into one of two lies: a calendar event so vague it means "whenever we get to it," or a rule so strict that admins quietly work around it. The patch cadence calendar decides when the window happens; this page is the policy for the hours themselves — the four rules every window runs on, when a window is actually required, how emergency work ratifies after the fact, and the one-line log that makes eleven consecutive windows look like the change process auditors and customers ask about.

1. The four rules every window runs on

Declared, not assumed. Every window gets a named owner, start and end clock times, the systems in scope, and the point of no return — the last moment where "roll it back" is still cheaper than "keep going." If nobody's name is on the window, it is not a window; it is a hope with a slot in the calendar. The cadence calendar gives you the third-Tuesday anchor; the named owner is what turns the anchor into an event someone prepares for.
Notified, on an SLA. Five business days notice to the people who use the systems in scope, 48 hours to the teams whose dependencies get touched (the group whose file server you are rebooting), and a same-day reminder that repeats start time, expected impact, and duration. A notice without a duration is an apology written in advance. The status page templates hold the words; this policy holds the clock.
Scoped, in writing, before the window opens. The plan exists as a document, not as intent: ordered steps with estimated minutes each, the verification command or page for every step, and the backout for every step that has one. "Since we're in there anyway" is the reason windows overrun — inside the window, anything not on the plan waits for the next window. The change management checklist is where the plan lives; the patch management checklist fills it for patch waves.
Verified, or rolled back — on a timer. The window closes only when the smoke checks pass: login works, the app renders, the nightly backup job fires, monitoring is green for ten straight minutes. If a check fails and the likely fix exceeds a quarter of the remaining window, roll back — the rollback checklist sets the criteria. Overrunning a window silently converts planned downtime into an incident, and the severity matrix decides what that incident gets called.

2. When a window is required — and when it is theater

Required: anything that interrupts service or can fail into one. Reboots, failover tests, firewall and routing changes, DNS changes, schema migrations, firmware updates, certificate replacements that touch the trust chain. If the failure mode of the change is an outage, it rides a window. The uptime budget exists precisely so this rule can be arithmetic instead of opinion.
Not required: read-only work. Access reviews, monitoring additions that do not change behavior, documentation, inventory counts. Forcing windows for these teaches the team that windows are paperwork, and paperwork gets skipped exactly when it matters. The access review and the asset inventory run any day of the week.
Emergency work bypasses the window — and ratifies within 24 hours. When the severity matrix says Lane 0 (actively exploited CVE, exposed auth, CISA KEV hit), patch hot per the patch cadence Lane 0 rule and deal with the mess. The override is legal; the undocumented override is not. Within 24 hours, one paragraph goes in the log: what ran, why it could not wait, what it broke, what the calendar now says. The first 30 minutes runbook covers the version where the patch is a response to something already on fire.

3. Freezes, holidays, and collisions

The freeze beats the window. During a declared freeze, the change freeze policy wins: the window does not exist for frozen systems that month, and the deferred work goes through the cadence page's four-line deferral card with a date — not a shrug. "It was in the calendar" has never once survived the conversation after a launch-week outage.
Suspensions are declared in writing. One line in the ops channel or the calendar event itself: "October wave suspended (launch week); resumes third-Tuesday November." A suspended window that still reads recurring in the calendar is how a patch wave lands on Christmas Eve with nobody watching it.
Never parallel-change the same path. When your window collides with a vendor's (the managed firewall's contract-mandated update night, the ISP's scheduled swap), sequence them, never overlap. The vendor outage runbook is for when the vendor breaks something anyway; the rule here is simply that two changes crossing in the night share no blame and no evidence.

4. Staffing: the second awake human

No solo scary changes. Anything in scope that can take the primary system down gets a second person awake — on the phone or on a call, not "ping me if it breaks." This is not a skill question; it is a 3 a.m. question. The tired brain that reads /var/log/old as "full of old logs, safe to empty" needs a second pair of eyes that is also awake. The on-call rotation template names who covers the window; the handoff checklist makes the window shift explicit so the day shift is not surprised by an 11 p.m. pager.
The owner owns the clock, not the keyboard. One person calls each go/no-go and the abort; everyone else executes. When the abort decision is made by committee at 1 a.m., every minute of debate is downtime. The window owner's only job during the window is the clock and the go/no-go.
Vendor hands are staffed hands. When a vendor's engineer is doing the work inside your window, someone from your team watches the whole time — screen shared, changes narrated. The escalation ladder is what you climb when their work slips; the log entry names both the vendor action and your watcher.

5. The paper trail that makes the window real

One log entry per window, same fields every time. Date, owner, systems in scope, what changed, verification results, duration, incidents (yes/no + link), deferrals with dates. Eleven consecutive entries is what "do you maintain a formal change process?" looks like as an answer on the customer security questionnaire — and it costs one line per month.
Planned downtime is still downtime — budget it. A 99.9% promise with a monthly two-hour wave is arithmetic, not aspiration: the downtime budget exists to catch exactly this, and the SLA template should name the window in its exclusions so the promise and the calendar agree.
Report the window in fixed format, rollbacks with the same calm as wins. The line in the weekly status report reads: "October window: 6/6 changes landed, 1 rollback (billing app, 22 minutes, verified), zero unplanned incidents." A rollback inside the window is the system working; only a rollback that becomes an incident earns the postmortem template.

Small-team honesty note: a five-person company does not need a change advisory board; it needs a recurring calendar event, a notice template, a written plan per window, and one log file. The trap this page exists to prevent is window theater — a recurring event that never has a plan, notices nobody sends, overruns nobody logs. If the notice for the next window is not drafted as you read this, the window is still a hope with a slot in the calendar. Send the notice, run the first window ugly, and let the log make it real.