Downtimes

A downtime silences notifications from the monitors it covers for a window of time. Use one for maintenance, a migration or a release, so planned work never pages anyone. When the window ends, notifications resume on their own: nobody has to remember to turn alerting back on.

What a downtime covers #

• Scope — the part of your estate the window applies to, as key:value terms separated by spaces: env:staging, service:checkout team:payments. * covers everything.
• Monitors — which monitors in that scope are silenced, by monitor tag. * silences every monitor in scope.
• Start and end — when the window opens and closes. Leave the end open for work whose length you do not know yet, and end it by hand.
• Recurrence — none, daily or weekly. A recurring downtime repeats the same window, so a nightly batch job or a weekly patch slot is one downtime rather than one a week.
• Message — why the window exists. It is kept with the downtime, so the next person to see it knows what was planned.

The list shows how many monitors each downtime matches right now, so a scope that silences more, or less, than you meant is visible before the window opens.

What happens during the window #

Monitors keep evaluating. Their status still changes, and the history still records what happened; only notifications are held back. That is the difference from muting, which silences a single monitor until someone unmutes it.

• Scheduled — the window has not started yet.
• Active — the window is open and its monitors are silent.
• Ended — the window closed, or it was cancelled.

Creating one #

Open Monitors → Downtimes and choose Schedule a downtime. Scheduling a silence is not a read, so even viewing the downtimes list needs the downtimes permission, which the Standard role and above hold; creating and cancelling one needs the permission to manage downtimes.

Onward #

How monitors evaluate and alert is Monitors. Where the alerts go when the window ends is Notification destinations.