A change calendar and maintenance windows for a small operations team

Goal

Make "what changed?" answerable in one look during an incident, keep risky changes out of the hours when nobody can respond, and give users notice of planned disruption before it starts.

Prerequisites

A shared calendar or a plain table that everyone who deploys can read and write; agreement on what counts as a change (deploys, schema migrations, DNS and certificate changes, provider maintenance, infrastructure upgrades, feature-flag flips with user impact); an incident channel where the calendar is linked.

Steps

1. Define the entry format: what, owner, start and expected end, affected systems, expected user impact (none, degraded, outage), rollback plan, verification step. One line each. A change without a rollback line is not scheduled.
2. Define standing windows: a routine window for low-risk changes during working hours, when the owner and a second person are reachable, and a maintenance window for disruptive work, announced on the status page in advance. State windows in one named time zone.
3. Define blackout rules: no disruptive change on the day before a holiday, during a launch, during an open incident, or when the change owner is also the on-call primary with no backup. Blackouts are calendar entries too, so they are visible.
4. Add provider events. Hosting and cloud providers announce maintenance; copy those into the same calendar so they are not mistaken for internal changes during an incident.
5. Before starting, the owner posts "starting <entry>" in the operations channel and "done, verified" or "rolled back" afterwards. Automated deploys post the same messages from the pipeline.
6. During an incident, the first question is the calendar: what started or finished in the last hours? Entries without an end time are the first suspects.
7. Review monthly: changes made outside windows, changes without rollback lines, incidents whose cause was a scheduled change. Adjust the rules rather than adding approval steps.

Expected result

Responders correlate symptoms with changes in minutes; disruptive work stops landing late on a Friday by accident; users see planned maintenance before it starts.

Limits and test basis

The 70% figure is the SRE book's report of Google SRE's finding, not a universal constant. A calendar that demands approval for every deploy slows delivery and gets bypassed; keep entry cost low and reserve approval for the maintenance-window class. No adoption rate or outage reduction is claimed.