Maintenance and silences
Planned work that should not page anybody, and how it differs from muting an alert.
There are two ways to stop being paged, and they mean different things.
| Silence | Maintenance window | |
|---|---|---|
| Scope | One alert or fingerprint | Everything matching a scope |
| Intent | "I know, I'm on it" | "This is planned, nothing is wrong" |
| Record | Somebody muted a page | Planned work, with a reason |
| Set up | On the alert | Settings → Platform → Maintenance |
Use a silence when you are already handling something. Use a maintenance window when you know in advance.
Creating a window
A window has a scope, a start, an end, and a reason. Scope can be services, servers, environments or tags.
Put a real reason in. Six weeks later, "why did nothing page during the incident on the 14th" is a question somebody will ask, and "maintenance" is not an answer.
What a window does and does not do
Does: suppress notifications for everything in scope for the duration.
Does not: stop evaluation. Rules keep running and alerts keep being recorded — you can see afterwards exactly what happened during the window, which is what makes the window safe to use.
Notifications are suppressed, not deleted. An alert that fires during the window and is still firing when it ends notifies then. That is deliberate: a window that swallowed an ongoing outage because it happened to start during planned work would be worse than no window at all.
Scheduled windows
Recurring work — a nightly batch, a weekly reindex — can have a recurring window rather than somebody remembering to create one.
If the thing you are suppressing is a warehouse query that only means something outside the batch, consider a run window on the rule instead. A rule that is not evaluated during the load is better than one that fires and is suppressed: the query is not run, so the warehouse does not do the work either.
Auditing
Every window and silence is in the audit log with who created it and when. A muted alert that nobody can account for is its own kind of incident.
Where this behaviour lives: frontend/src/app/maintenance/, backend/internal/handler/maintenance_handler.go. If the code and this page disagree, the code is right — please fix the page.
Part of Incidents and on-call — Turning a reading into a page, and a page into a resolved incident.