Maintenance windows
Purpose: Plan and execute planned platform work — upgrades, reindexing, infra changes — with authoring and traffic protected.
Who this page is for
| Audience | Why it matters to you |
|---|---|
| Platform engineers | Executors |
| Tech leads | Schedulers and communicators |
Two kinds of window
| Kind | Examples | User impact design |
|---|---|---|
| Routine (automated) | Revision GC, purges, datastore GC (maintenance tasks) | None if scheduled off-peak and monitored — verify they RUN, don't assume |
| Planned work (manned) | SP installs, index rebuilds, infra moves, restore rehearsals | Author downtime and/or reduced publish redundancy — communicated and time-boxed |
Planning a manned window
- Author-impacting (author restart/upgrade): authors notified with a hard start/stop; workflows and scheduled activations audited beforehand (what fires mid-window?); replication queues drained first.
- Publish-impacting: one instance at a time out of LB (traffic tolerance = the N−1 sizing you did in capacity planning ⚡); never both tiers destabilised simultaneously.
- Every window has: runbook with numbered steps + verification per step, a rollback point ("if step 4 fails, we restore X and stop"), a named runner and a named checker (two people — solo maintenance windows produce the best incident stories and the worst outages).
The window itself
T-0 announce start; silence deploy-suppressed alerts (not ALL alerts)
step execute → verify → log timestamp+result in the window doc
...
T-end full-platform verification (same smoke as a deploy) → announce close
un-silence alerts → watch dashboards for one cycle → file follow-upsThe window doc (steps, timestamps, deviations) is not bureaucracy: next quarter's window starts from it, and the "what changed on the 14th?" incident question gets a real answer (incident response).