Maintenance windows: how suppression works

Maintenance windows let you schedule planned downtime and stop Pingara from paging you for it. A window covers the monitors it names, whether or not those monitors are on a status page. You create a window from a status page's editor, but the page only decides what All monitors on this status page means, how the window shows to your visitors, and which subscribers hear about it. The checks still run during a window, so a monitor that no window covers fires incidents and alerts exactly as it would on any other day.

Pro plan required. Maintenance windows are a Pro feature. Free-plan organizations can't create or edit them.

Which monitors a window covers

You create and configure maintenance windows from a status page's editor (its Maintenance tab, with Schedule maintenance). The window's monitor scope has two settings:

Specific monitors. The list shows every monitor in your organization, not only the ones on this page. Each monitor you select is covered for as long as the window is in progress, whether or not it is attached to this status page.
All monitors on this status page. The window covers the monitors attached to the page. Coverage is resolved live against the page's current monitor list, not a snapshot taken when you created the window, so a monitor you add to the page later is covered automatically and a monitor you remove from it stops being covered.

When a check comes back down or degraded, Pingara looks for an in-progress window that covers the monitor at that moment. A window covers a monitor when the monitor is named in it, or when the window is set to all monitors on its page and the monitor is attached to that page.

Setting up suppression for a monitor

Open the Maintenance tab of any of your status pages. The page doesn't need to include the monitor, and it can be private. A private status page still supports maintenance windows; it just isn't reachable at a public URL. If you don't have a status page yet, see Creating Status Pages.
Create the maintenance window, and either select the specific monitors it should cover, or choose All monitors on this status page to cover everything attached to that page.
Choose what the window suppresses. These are two independent toggles, not one:

Toggle	What it does	What still happens
Suppress incidents	No incident is opened for a down or degraded transition during the window	Checks keep running and check results are still recorded
Suppress alerts	No notification is sent for incident creation or recovery during the window, and no notification is sent when a monitor is paused or resumed	If an incident is still created (suppress incidents off), it's just silent

You can suppress alerts without suppressing incidents, useful when you want the incident history and duration recorded for later review, just without paging anyone. You can also suppress incidents without suppressing alerts, though in practice there's nothing left to alert on if no incident opens.

If an incident opens during a window that suppresses alerts and the monitor is still down when the window ends, Pingara sends the down alert it held back, once, on the first check after the window that confirms the monitor is still down. Status page subscribers get it too. Escalation, if your alert policy uses it, starts counting from that alert rather than from when the incident opened (or from the first check after the window, if checks can't confirm the outage, for example because one of the monitor's regions has stopped reporting). An incident someone acknowledged during the window still gets this alert, but acknowledging it still stops escalation. If the monitor recovers before the window ends, nothing is sent afterwards. If it recovers within 15 minutes of the first check after the window ends, before that held-back alert goes out, and no escalation notice went out meanwhile, no recovery notice is sent either, because nobody was told it was down. If it takes longer than that to recover, the recovery notice is sent, so you still learn an outage happened. The incident and its timeline record the outage either way.

Overlapping windows

If more than one in-progress window covers a monitor, the windows combine. A toggle applies if any covering window has it on, so a window with a toggle off never undoes another window's. For example, if one window suppresses only incidents and another suppresses only alerts, the monitor has both suppressed while they overlap. This holds for windows on the same status page and on different pages, and it doesn't depend on which window you created first.

Pausing and resuming during a window

A window that suppresses alerts also withholds the notifications that pausing or resuming a monitor sends. If you pause or resume a covered monitor while such a window is in progress, no "Monitor paused" or "Monitor resumed" notification goes out, even if your alert policy has the Pause / resume option on. Nothing is sent afterwards to make up for it. A window that suppresses only incidents doesn't withhold them.

Webhook subscriptions are different. They still receive monitor.paused and monitor.resumed, because those events report a change a member made, not a platform-detected outage. See Developer API.

What doesn't change during a window

Maintenance windows don't pause monitoring. Checks run on schedule, check results are stored, and your uptime and Apdex history for the window's duration reflects whatever the checks actually returned. Only incident creation and alert delivery are affected, and only for the toggles you enabled. A test alert you send from a monitor's page is the exception: it still delivers during a window, so you can check your channels at any time. If you want checks to stop entirely, pause the monitor instead (see Understanding the Dashboard); pausing and a maintenance window are different tools for different situations.

Where you see maintenance in Pingara

While a window is in progress, the signed-in app marks the monitors it covers. The mark is a Maintenance marker beside a monitor's status. Maintenance is never a status of its own, and the marker never replaces the status: the status you see is still the latest check result.

Dashboard and Monitors list. A covered monitor shows the Maintenance marker beside its status. A monitor covered only by a window that suppresses nothing still shows it, because the window covers the monitor.
Monitor page. The marker shows beside the status, and a Maintenance in progress notice appears under the header. For each window that covers the monitor, it shows the window's title, the status page it belongs to, when it ends, and the window's own settings: "Suppresses incidents and alerts", "Suppresses incidents", "Suppresses alerts" or "Does not suppress incidents or alerts". Owners, admins and editors get a link from the status page's name to that page's Maintenance tab. Other members see the name as plain text.

Under the windows, the notice says what the combined settings mean for the monitor. When more than one window covers it, the settings combine as described in Overlapping windows above. The sentences you can see are:

"Checks keep running, and the status shown is the latest check result."
"Incidents and alerts work as usual." when no covering window suppresses either.
"No new incident opens for this monitor while maintenance is in progress." when a covering window suppresses incidents, or "Incidents still open as usual." when none does.
"Alerts are sent as usual." when no covering window suppresses alerts. When one does: "Alerts and status page subscriber notices are held back. A held-back down alert is sent once, later, if a check confirms the monitor is still down after alerts stop being held back. Recovery notices held back are not sent later."

The markers and the notice come and go as windows start and end, within about a minute of the window's scheduled end. They are for members of your organization, including viewers. Visitors to your status page see the public label described below instead.

If many windows are in progress at once, Pingara may not be able to check them all. When that happens, the dashboard and the Monitors list show this line above the monitors, and a monitor's page shows it when no window was found for that monitor: "Not every maintenance window in progress could be checked, so some maintenance may not be shown here." A monitor with no marker is not proof that no window covers it. Checks and suppression are not affected, because the check pipeline looks up windows on its own for every check.

Incidents with a held-back down alert

When a window that suppresses alerts is in progress, Pingara holds back the down alert for an incident that opens (see Setting up suppression for a monitor above). The incident list and the incident page mark an incident whose down alert was held back. The mark comes from the incident's own record, so it stays after the window ends, and it shows nothing for an incident that never had a down alert held back, including incidents from before Pingara recorded this.

Case	Marker in the incident list	Sentence on the incident page
The held-back alert was sent	Down alert held, then sent	"Maintenance held back the down alert for this incident. It was sent at (time), once alerts were no longer held back."
The incident is still open and the alert is still owed	Down alert held	"Maintenance held back the down alert for this incident. It is sent once, on the first check that confirms the monitor is still down while no maintenance window holds back its alerts."
The incident resolved before the alert was sent	Down alert held, not sent	"Maintenance held back the down alert for this incident, and it was not sent before the incident resolved."

"Sent" means Pingara dispatched the alert. The incident timeline shows what happened on each channel. These marks cover the down alert only.

What your visitors see

A public status page shows the windows created on that page, and it counts, names and marks only those windows' monitors that are on that page. A monitor a window names but the page doesn't include is still suppressed, but visitors don't see it as affected. A window created on a different status page doesn't appear on this page at all, even when it covers one of this page's monitors. That monitor is still suppressed, but this page shows no count, name or label for it.

Count and names. An in-progress window and each upcoming window show how many services are affected and which ones, for example "2 services affected", with the names of those monitors.
Whole-page windows. A window that covers all of the page's monitors says "All services affected" instead of listing them.
Maintenance label. While a window created on this page is in progress, each service it covers shows a "Maintenance" label beside its status. The label sits next to the status and doesn't replace it. Upcoming windows don't label any service.
Windows that name only off-page monitors. If none of the monitors a window names is on the page, the page shows the window with no count and no service names.

When you pick monitors in the window dialog, any monitor that isn't on the status page you're editing shows this line under its name: "Not on this status page. Visitors won't see it as affected, but it's still suppressed." You can still pick it.

What your subscribers see

Status page subscribers get one email when a window starts and one when it ends. Those emails name only the covered monitors that are attached to that page. A monitor the window names but the page doesn't include is still suppressed, it just isn't listed in that page's emails.

Next Steps

Creating Status Pages - Set up the status page you schedule windows from
Understanding Incidents - How incidents behave outside a maintenance window
Setting Up Alerts - Configure the alert policies a maintenance window temporarily silences