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 piece is the policy for the hours themselves — the four rules every window runs on, when a window is actually required, and the paperwork that makes the whole machine auditable.
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.
Notified, on an SLA. Five business days to the people who use the systems in scope, 48 hours to teams whose dependencies get touched, and a same-day reminder that repeats start time, expected impact, and duration. A notice without a duration is an apology written in advance.
Scoped, in writing, before the window opens. Ordered steps with estimated minutes each, the verification command 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 one.
Verified, or rolled back. The window closes only when smoke checks pass — login works, the app renders, the backup job fires, monitoring is green for ten minutes. If a check fails and the likely fix eats more than a quarter of the remaining window, roll back. Overrunning a window silently converts planned downtime into an incident.
2. When a window is required — and when it is theater
Required: anything that interrupts service or can fail into one. Reboots, failovers, firewall and routing changes, DNS, schema migrations, firmware.
Not required: read-only work. Access reviews, monitoring additions, documentation. Forcing windows for these teaches the team that windows are paperwork — and paperwork gets skipped exactly when it matters.
The exception: emergency work bypasses the window, then ratifies within 24 hours. When the severity matrix says Lane 0 — actively exploited CVE, exposed auth — patch hot, then put one paragraph in the log: what ran, why it could not wait, what it broke. The override is legal; the undocumented override is not.
3. The second awake human
No solo scary changes. Anything in scope that can take the primary system down gets a second person awake — 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.
And the owner owns the clock, not the keyboard. One person calls each go/no-go; everyone else executes. When the abort decision is made by committee at 1 a.m., every minute of debate is downtime.
4. The one-line log that makes it real
One entry per window, same fields every time: date, owner, systems, what changed, verification results, duration, incidents, deferrals with dates. Eleven consecutive entries is what "do you maintain a formal change process?" looks like on a customer security questionnaire — and it costs one line per month.
Planned downtime is still downtime: a 99.9% promise with a monthly two-hour wave is arithmetic, not aspiration. The SLA should name the window in its exclusions so the promise and the calendar agree.
The full policy — freeze-vs-window collisions, vendor hands in the window, the fixed-format report line — is on the site:
Maintenance Window Policy for Small Teams (Rules for the Hours When Change Is Allowed)
Pair it with the patch cadence calendar (the when) and the change freeze window policy (the when not). If you want the kit versions — incident response, comms templates, the first-30-minutes runbook — the Ops Starter Kit ($14) and the Automation Starter Pack ($19) are live on Gumroad.
HIVE80lab publishes one practical ops-note per day for small teams — free, no signup, no fluff.
Top comments (0)