Muting and downtimes

Who can do this: operators and organization administrators. Viewers can see mutes and downtimes but cannot create, remove or cancel them.

Both features stop notifications for a service without changing how it is monitored. Use a mute for an open-ended silence you will lift by hand, and a downtime for a planned window with a start and end, such as cleaning, calibration or a defrost cycle.

	Acknowledgement	Mute	Downtime
Needs an active alarm	Yes	No	No
Stops alarm and repeat notifications	While severity is at or below the acknowledged one	Yes	Yes
Stops acknowledged, recovered, stale and data-recovered notifications	No	Yes	Yes
Alarm still shown in Active Alarms	Yes	Yes	No, hidden while the window is in progress
Ends	On recovery, data resume, limit change, or by hand	By hand only	At the end time, or by cancelling

Mute

A mute switches off every notification for a service: alarm, repeat, acknowledged, recovered, stale, repeat stale and data recovered. It applies to all channels of the service and to all recipients. Nothing else changes: readings are still evaluated, alarms are still raised and recorded, the badge still turns WARNING or CRITICAL, and the alarm still appears in Active Alarms.

A mute has no duration and no expiry. It stays in place through any number of alarms and recoveries until someone unmutes the service.

Mute a service

1. Open the service page.
2. Below the alarm limits, click Mute notifications for this service. There is no confirmation dialog and no reason box; the reason is recorded as "Muted from service page".
3. The block changes to "Notifications muted by your name since now — Muted from service page" with an Unmute button. After a page reload, "since now" becomes the time of the mute in your profile timezone.

The dashboard card for the service shows "🔕 Notifications muted: Muted from service page" while the mute is in place.

Nobody is notified that the service was muted. The mute is recorded in the audit log.

If you do not have the operator role, the block reads "Notifications active — muting requires operator access".

The mute block on a service page after muting, with the Unmute button.

Unmute a service

1. On the service page, click Unmute. There is no confirmation dialog.
2. The Mute notifications for this service button returns.

Nobody is notified that the service was unmuted. Notifications resume on the next once-a-minute check:

• If an alarm is active and its first notification was never sent (because it was raised while muted), the alarm notification is sent now, provided the band's Delay has passed and nothing else suppresses it. If the alarm was notified before the mute, the next repeat is sent once the repeat interval since the last notification has passed.
• Events that happened while muted are announced late. Acknowledgements, recoveries, stale periods and data resumptions recorded during the mute are sent after you unmute, at most one of each type (the most recent), and only if their own conditions still hold, for example a Recovered is sent only for an episode whose alarm had been notified. Expect a short burst of messages after unmuting a service that had activity while it was muted.

Downtimes

A downtime is a window with a start and an end during which the service is treated as intentionally out of service:

• Every notification type is suppressed while the window is in progress, exactly as for a mute.
• The service's alarms are hidden from Active Alarms on the dashboard for the duration. The dashboard card shows "⏸ In downtime: reason", and the service page shows a Currently in downtime banner with the reason, the window and "Scheduled by".
• Monitoring itself does not pause. Readings are evaluated, alarms are raised and recovered, stale is detected, and everything is recorded in Recent Events as usual.

A downtime can be scheduled for the future or started immediately by entering a start time that has already passed.

Schedule a downtime

Downtimes are created from the service page; the dashboard only lists the ones in progress.

1. Open the service page and scroll to Downtimes for this service.
2. Click Schedule new downtime for this service to open the form.
3. Fill in the fields and click Schedule Downtime.

Field	Meaning	Validation
Reason (placeholder "Reason (e.g. cleaning)")	Why the service is going down. Shown on the dashboard card, the service banner and in the downtime lists.	Required. A blank or spaces-only reason is refused: "Reason is required".
Start (first date/time field)	When suppression begins, in your profile timezone. Pre-filled with 5 minutes from now.	Required.
End (second date/time field)	When suppression ends, in your profile timezone. Pre-filled with 1 hour from now.	Required. Must be later than the start: "End time must be after the start time". Must be in the future: "Downtime window is in the past (its end time has already passed)".

A refused form shows its message on its own, as a plain page. Use your browser's back button to return to the service page and correct the form.

Times are entered in your profile timezone

The start and end fields are read in the timezone set on your profile (see Your profile and notification settings), and the pre-filled values are the current time in that timezone. Pulse converts the window to UTC for storage and shows it back to you in your profile timezone. For example, with the timezone America/Vancouver, a downtime entered as 09:00 to 11:00 is stored as 16:00 to 18:00 UTC during Pacific Daylight Time and is listed as 09:00 to 11:00. If your profile timezone is not the local time of the site, convert before you type.

The page reloads. If the window has already started, it appears under Downtimes for this service with its reason, the start and end in your profile timezone, and "by your name".

Future downtimes are not listed until they start

Both lists show only windows that are in progress right now. A window with a start time in the future is saved, but it is not shown anywhere and cannot be cancelled until its start time arrives; after saving one, the service page still reads "No active downtimes for this service." Note the times you entered, and check the list once the window has started. Organization administrators can confirm the window was created in the audit log.

Nobody is notified that a downtime was scheduled. It is recorded in the audit log.

The Schedule new downtime for this service form with a reason and start and end times (shown in your profile timezone).

Where downtimes are listed

Place	Shows	Times
Service page, Downtimes for this service	The service's windows in progress right now, with the reason, the window and "by …". "No active downtimes for this service." when there are none.	Your profile timezone
Dashboard, Current Downtimes	Every window in progress right now across your organizations, with the service name, the reason, the window and "Scheduled by". Refreshes every 15 seconds. "No active downtimes." when there are none.	Your profile timezone

Cancel a downtime

There is no way to edit a window or shorten it; to end a downtime early, cancel it. Only a window that is in progress can be cancelled, because only those are listed.

1. Find the window under Downtimes for this service on the service page, or under Current Downtimes on the dashboard.
2. Click Cancel.
3. Confirm "Cancel this downtime?".

The window is deleted and the list refreshes. Any operator in the organization can cancel any window, not only the person who scheduled it. Cancelling is recorded in the audit log; nobody is notified.

Note

Immediately after a cancel, the refreshed list shows the remaining windows in UTC with a "UTC" suffix. Reload the page to see them in your profile timezone again.

On the dashboard the Cancel button is shown for every role. If your role is viewer, the cancellation is refused with "Operator role or higher required to cancel downtime" and the window stays in place. On the service page the button is shown to operators only.

What happens at the start and end of a window

An alarm is active when the window starts. It disappears from Active Alarms, and repeats, escalations, acknowledgements, recovery and stale notifications for the service are all suppressed until the window ends. The alarm remains visible on the service page and in Recent Events.

An alarm is still active when the window ends. It reappears in Active Alarms. On the next once-a-minute check:

• If no alarm notification was ever sent for this episode (the alarm was raised during the window, or before it but still inside its Delay), the alarm notification is sent now; the Delay counts from when the alarm was raised, so it has normally already passed.
• If the alarm was notified before the window, the next repeat is sent once the repeat interval since the last notification has passed.

An alarm recovered during the window. The recovery was recorded as usual. A Recovered notification is sent after the window ends only if an alarm or repeat notification had been sent for that episode before the window started. An alarm that was raised and recovered entirely inside the window sends nothing.

Other events during the window. As after an unmute, acknowledgements, stale periods and data resumptions recorded during the window are announced after it ends, at most one of each type.

A scheduled window does not stop a stale service from being marked stale, and it does not clear acknowledgements.