Maintenance windows
A maintenance window does not switch monitoring off and does not hide what happened. Inside the window, incidents are still recorded, with a "suppressed" note in their timeline; they simply arrive already acknowledged, so nobody is paged, digests leave them out, and they do not count in your response-time statistics. When the window ends, whatever is still broken is still open, waiting for a real acknowledgement.
Creating a window
Alerting, Maintenance tab.
- One-off: a start and an end, for planned work you know the timing of.
- Repeating: daily or weekly, anchored to a start time and a duration, for recurring jobs such as nightly backups that always spike the disk or the load. Occurrences are computed from the anchor; there is no list of dates to maintain. The anchor keeps the local time of the person who created it: a window at 03:00 stays at 03:00 across the switch to and from daylight saving time, like the cron job it covers.
- Right now: the 2 hours button opens a window that starts immediately, for the "I am on the box now" case.
Each window targets either the whole workspace or specific hosts. A window on one host does not touch incidents born on another.
What is and is not suppressed
Suppression applies to incidents born inside the window. An incident that opened before the window and is still open when the window starts keeps its state; a window is not a way to acknowledge existing incidents in bulk.
Event-born incidents (a failed task, an integrity change) are suppressed like any other. Cron heartbeat silence is suppressed too, which is the right tool when a job is intentionally paused for a migration.
Automating it
Deployment pipelines can open a window before a rollout and close it after through the
REST API (/maintenance) or through an AI agent with the
open_maintenance tool over MCP. A window opened this way behaves exactly like
one created in the console and is attributed to the token that opened it in the audit log.