Maintenance

Announcing a maintenance window so it is recorded rather than paged.

What announcing maintenance does

A maintenance window is a durable, announced span of time covering an explicit set of monitors and public status-page components. Announcing a window does not stop monitoring: nodes keep checking, results are stored, and consensus is computed exactly as it always is. What a live window changes is narrower and deliberate — whether a qualifying state change opens a new incident, and whether an escalation is delivered — so that work already known about is recorded as maintenance rather than paged as a surprise.

What is suppressed, and what is recorded

While a window is active and covers a monitor, a DOWN observation that would otherwise confirm a new incident still consumes its evidence — the confirmation streak still advances — but the action taken is suppression rather than opening an incident. See Incidents for how confirmation works generally. Nothing about the underlying observation is altered or hidden: the check result, the consensus state, and the historical timeline all record exactly what happened, during a window or not.

Announced time versus applied time

What an operator announces — the window's stated start and end — and what actually happened — when it was activated, completed, or canceled — are recorded separately rather than reconciled into one fiction. If the control plane was not running at a window's announced start, the record states when the scheduler's repair pass actually applied the transition, not a backdated instant. A window's status is not inferred from the clock alone; it moves through an explicit lifecycle, applied by a background pass that also handles catching up after downtime.

Lifecycle

scheduled -> active      at or after the announced start
scheduled -> canceled    the window never ran
active    -> completed   at or after the announced end
active    -> canceled    ending the window early

completed and canceled are terminal; nothing about a finished window's record may change afterward, because it is a statement about work that already happened.

Overlap

Within one tenant, two live windows may not overlap in time while they share a covered monitor or component — two windows both claiming the same monitor at once would leave "which window covered this" with two answers. Unrelated maintenance at the same hour, covering different monitors, is ordinary and is allowed.

This article is part of this repository and is served by the same binary, so what you read here is the documentation for the version you are running.