Alert Suppression and Maintenance Windows: How to Silence Alerts Safely (2026)
Quick answer: Alert suppression is the practice of stopping notifications for specific alerts, on purpose and for a limited time, while monitoring keeps running. A maintenance window is the most common reason to do it: a scheduled period of planned work, such as an upgrade or migration, during which alerts for the affected systems are expected and shouldn't page anyone. Safe suppression has four rules: keep evaluating and recording alerts but block the notifications, scope the suppression to only the systems being worked on, give it an automatic end time, and never suppress the alerts that would tell you the maintenance itself has gone wrong.
It's 2 a.m. The platform team is upgrading the primary database. The upgrade restarts the cluster, which is expected. What wasn't planned: 140 alerts from the database, the API, the queue workers and the synthetic checks, paging three on-call engineers on three teams who have no idea an upgrade is happening.
By the third time this happens, those engineers start ignoring alerts that arrive during the night. That's how planned work creates alert fatigue, and how the one real failure on the night of the next upgrade goes unnoticed.
Alert suppression fixes the first problem without creating the second. This guide covers what alert suppression is and how it differs from silencing, acknowledgment and deduplication, the types of suppression, how to set up a maintenance window step by step, what you should never suppress, a worked example, and how common monitoring and incident tools implement it.
What is alert suppression?
Alert suppression is the deliberate, time-limited blocking of alert notifications for a defined set of systems or alert rules. The monitoring system keeps checking metrics and recording alert state, so nothing disappears from history, but it doesn't page, email or post to chat while the suppression is active.
That distinction matters. Suppression stops the interruption, not the observation. When the suppression ends, anything still firing becomes visible immediately, and the record of what happened during the window is available for the postmortem.
What is a maintenance window?
A maintenance window is a scheduled period of planned work on specific systems, with a defined start time, end time, owner and scope. Upgrades, migrations, patching, failover tests and hardware replacements all happen inside maintenance windows. Alert suppression is how the monitoring stack is told about the window, so that the alerts the work is expected to cause don't page anyone.
In mature teams, every maintenance window is linked to an approved change record, and the suppression is created from it, not set up by hand.
Suppression vs. silencing vs. acknowledgment vs. deduplication
These terms are often used interchangeably, but they do different things:
Term | What it does | When it applies | Example |
|---|---|---|---|
Suppression | Blocks notifications for matching alerts for a set period; alerts are still evaluated and recorded | Planned work, known issues, dependent failures | Mute alerts for the |
Silence | A manual, ad hoc suppression, usually created on the spot | An engineer is already working on the issue, or a known noisy alert | "Silence disk alert on host-14 for 2 hours" |
Acknowledgment | Records that a person has seen an alert and owns it; stops escalation, not the alert | Incident response | On-call acknowledges the page and starts triage |
Deduplication | Merges repeated copies of the same alert into one | Always on | 300 identical CPU alerts become one (alert deduplication) |
Inhibition | Mutes alerts that are a consequence of another, higher-priority alert | Dependency failures | "Database down" mutes the 40 "API can't reach database" alerts |
Correlation | Groups related alerts from different sources into one incident | Always on | Database, API and synthetic alerts become one incident (alert correlation) |
A useful rule: deduplication and correlation reduce noise from real problems; suppression and silencing reduce noise from expected events. You need both, and they shouldn't be confused. Suppressing a real problem because it's noisy hides it; it doesn't fix it.
Types of alert suppression
Most teams use five kinds of suppression. Each solves a different noise problem, and each has its own risk.
Type | How it works | Best for | Main risk |
|---|---|---|---|
Scheduled maintenance window | Suppression is created in advance for a scope and time range, often from a change record | Upgrades, migrations, patching, planned failovers | Work overruns the window, or the scope is too broad |
Ad hoc silence | An engineer mutes a specific alert on the spot for a short time | An alert that's already being worked on; a known issue awaiting a fix | Forgotten silences that never expire |
Dependency suppression (inhibition) | When a root alert fires, alerts that depend on it are muted automatically | A database or network failure that breaks every service above it | A badly drawn dependency hides an unrelated failure |
Time-based suppression | Some alerts only notify during defined hours | Non-urgent alerts for internal tools, development and test environments | A real production problem waits until morning |
Flap suppression | Alerts that fire and resolve repeatedly are held until they're stable | Network links, health checks with tight thresholds | Masking an intermittent fault that's getting worse |
Two of these, inhibition and flap suppression, are really noise-reduction rules that run all the time. The other three are temporary by design. The safety rules in the next sections apply to all five, but they matter most for scheduled windows and ad hoc silences, because those are created by people under time pressure.
How to set up a maintenance window safely
A safe maintenance window takes about ten minutes to plan. Skipping that planning is how planned work turns into an unplanned incident nobody notices.
Link it to a change record. Every window starts from an approved change with an owner, a description, a start time and an end time. The change record is the source of truth; the suppression is created from it. See release management best practices for how changes are approved.
Scope it as narrowly as possible. Suppress the specific hosts, services or alert rules the work will affect, not the whole environment or a whole team's alerts. If you're upgrading one database cluster, suppress that cluster and the alerts that directly depend on it, nothing else.
Set an automatic end time. Every suppression needs a hard expiry tied to the change schedule. Add a small buffer, such as 15 minutes, but never leave a window open-ended. A suppression that has to be removed by hand will eventually be forgotten.
Keep evaluating, block only notifications. Alerts should still be evaluated and recorded during the window. That way, anything still firing when the window closes notifies immediately, and the window's history is available afterwards.
Exclude the alerts that matter regardless. Decide in advance which alerts still page during the window: user-facing synthetic checks, security alerts, and alerts for systems outside the scope. The next section lists what to keep.
Tell people. Post the window in the team channel, tell the on-call engineers for dependent services, and update the status page if customers will notice. On-call engineers should be able to see what's suppressed, by whom and until when.
Watch the end of the window. The riskiest moment is when the window closes. Have the change owner confirm that alerts are clear before the window ends, and extend it deliberately, with a note, rather than letting it expire into a page storm.
Review it afterwards. Check whether the window overran, whether alerts fired that weren't expected, and whether the scope was right. Feed anything surprising into the next change.
If the work overruns, extend the window explicitly and record why. Don't widen the scope to hide alerts you didn't expect: unexpected alerts during maintenance are often the first sign the change has gone wrong.
What you should never suppress
Suppression is meant to hide expected noise, not real risk. These alerts should keep paging during a maintenance window, even for the systems being worked on:
Keep paging | Why |
|---|---|
User-facing synthetic checks and SLO burn-rate alerts for journeys that should stay up | If customers are affected when they shouldn't be, the maintenance has failed. Burn-rate alerts measure exactly that; see error budgets. |
Alerts for systems outside the window's scope | A broad suppression is the most common way an unrelated outage goes unnoticed during planned work. |
Security alerts | Attackers don't respect maintenance windows, and changes temporarily weaken defenses. |
Data integrity and backup alerts | Replication lag, failed backups and corruption checks are the first signs that a migration is losing data. |
Capacity limits that can't recover on their own | Disk-full, quota and certificate-expiry alerts can turn a short window into a long outage. |
Alerts that the window should end | An alert that fires if the window or the change runs past its planned end time. |
A simple test before creating any suppression: if this alert fired during the window, would we want to know? If the answer is yes, it stays on. If the answer is "only if it's not because of our change", keep it on and let the change owner judge it.
Worked example: a database upgrade window
An illustrative scenario. The platform team plans a minor version upgrade of the orders-db cluster, approved as a change with a window of 02:00 to 03:00.
The suppression setup:
Scope: alerts from the three
orders-dbhosts, plus an inhibition rule that mutesorders-api"database connection failed" alerts whileorders-dbis in maintenance.Expiry: 03:15, the planned end plus a 15-minute buffer.
Kept on: the checkout synthetic check, the checkout SLO burn-rate alert, replication and backup alerts, and everything outside
orders-dbandorders-api.Announced: in the platform and payments channels, with the change link, and on the internal status page.
What happened:
Time | Event | Notified? |
|---|---|---|
02:00 | Window opens; suppression becomes active | — |
02:06 | Cluster restarts node by node; 38 database alerts and 52 API connection alerts fire | No: suppressed and recorded |
02:31 | Upgrade completes; database alerts clear | No |
02:38 | Checkout synthetic check starts failing for EU users | Yes: pages the payments on-call engineer |
02:44 | Triage links the failure to a connection-pool setting the new version handles differently | — |
02:52 | Change owner extends the window to 03:45, with a note on the change record | — |
03:10 | Pool setting corrected; checkout recovers | — |
03:45 | Window closes; no suppressed alerts still firing | — |
Why it worked. The 90 expected alerts never woke anyone. The one alert that mattered, real customer impact on checkout, paged within minutes, because the synthetic check was deliberately kept outside the suppression. If the team had suppressed "everything for orders" for three hours, the checkout failure would have been invisible until customers complained.
What went into the review: the connection-pool behavior was added to the upgrade runbook, and the next upgrade's window was planned 30 minutes longer.
How common tools handle suppression and maintenance windows
Every major monitoring and incident tool has a version of suppression, usually under a different name. The concepts above map to them like this:
Tool | Feature name | How it works | Watch out for |
|---|---|---|---|
Prometheus Alertmanager | Silences, inhibition rules, time intervals | Silences match alerts by label for a start and end time, with a comment and creator. Inhibition rules mute target alerts while a source alert fires. Time intervals mute routes on a schedule. | Silences are created by label matchers; a loose matcher silences far more than intended |
Grafana Alerting | Silences, mute timings | Silences for ad hoc muting; mute timings for recurring schedules on notification policies | Mute timings apply to a whole notification policy, not a single alert |
Datadog | Downtimes | One-time or recurring downtimes scoped by monitor, tag or group; monitors keep evaluating | A downtime scoped by a broad tag can mute unrelated monitors |
Zabbix | Maintenance periods | Hosts or host groups in maintenance, with or without data collection | "No data collection" leaves a gap in history; prefer "with data collection" |
Microsoft SCOM | Maintenance mode | Objects such as computers, groups or monitors are placed in maintenance mode for a set duration, scheduled or on demand; alerts aren't raised for them | Maintenance mode on a parent object can cover far more than the work being done |
Splunk | Alert throttling; maintenance windows in Splunk ITSI | Throttling suppresses repeat triggers of a saved-search alert for a period. In ITSI, maintenance windows stop episodes and alerts for services and entities. | Throttling is per alert and isn't a maintenance window; plan both separately |
Dynatrace | Maintenance windows | Planned or unplanned windows, with options to keep detecting problems, detect without alerting, or disable detection | Disabling detection removes the record you'll want for the review |
Elastic | Maintenance windows | Alerts are still generated during the window, but no notifications are sent | Recovery notifications are suppressed too if recovery happens inside the window |
ThousandEyes | Alert suppression windows | Windows assigned to tests or alert rules, shown on the test timeline | Windows assigned to many tests can hide a real network event |
ServiceNow Event Management | CI maintenance | Alerts for configuration items in maintenance are suppressed by default, usually driven by change records | Depends on an accurate CMDB; an unmapped CI isn't covered |
PagerDuty | Maintenance windows; suppress rules in event orchestration | Services in a maintenance window don't create incidents. Event rules can also suppress matching alerts, which are kept but don't create incidents or notify. | Maintenance windows apply to whole services; suppress rules apply to every matching event until someone removes them |
Moving off PagerDuty? Maintenance windows and suppression rules are among the settings teams rebuild first when they switch tools. See ITOC360 vs PagerDuty for how service-scoped maintenance windows and alert suppression carry over.
When alerts flow from several monitoring tools into one incident platform, set suppression in one place where possible. Suppressing in the monitoring tool and again in the incident platform makes it hard to know, at 2 a.m., why an alert didn't page.
Common alert suppression mistakes
Suppressions with no end time. A silence created "for now" during an incident is still active three weeks later. Every suppression needs an expiry, and anything longer than a day should need a second approval.
Scope that's too broad. "Mute everything tagged
env:prodfor the upgrade" hides every unrelated failure for the duration. Scope to hosts, services or alert rules, never to whole environments.Suppressing instead of fixing. An alert that's silenced every week isn't a maintenance problem; it's a bad alert. Tune it, change its threshold or delete it. See what is alert noise.
Turning off monitoring instead of notifications. Disabling checks or data collection removes the history you need to review the change and leaves no warning when the window ends.
No one told the on-call engineers. Engineers for dependent services see their alerts go quiet, or loud, without knowing why. Announce windows where on-call engineers actually look.
Letting the window expire into a page storm. Work overruns, the suppression ends on schedule, and dozens of alerts page at once. Extend deliberately, before the window closes.
No audit trail. Nobody can say who created a silence, why, or for which change. Record the creator, the reason and the change reference for every suppression.
Suppressing in several tools at once. Monitoring, alerting and incident tools each have their own suppression, and nobody knows which one swallowed a page.
Measuring and auditing suppression
Suppression is a control, and like any control it needs to be checked. Review these five numbers monthly:
Metric | What it tells you | Warning sign |
|---|---|---|
Active suppressions right now | How much of your monitoring is currently muted | Any suppression with no linked change or no end time |
Suppressions older than 24 hours | Forgotten silences | More than zero without a recorded reason |
Alerts suppressed per window | Whether windows are scoped well | Large counts for systems outside the planned scope |
Windows that overran | How realistic change plans are | Overruns becoming normal for one team or system |
Incidents that started during a window | Whether maintenance is causing real impact | Impact discovered by customers rather than by the alerts left on |
For every suppression, keep an audit record: who created it, when, the scope, the end time, the reason and the change reference. It makes postmortems possible, satisfies change-management and compliance reviews, and answers the question every on-call engineer eventually asks: "why didn't this page me?"
Treat suppression data as part of your wider alert management review. If the same alerts are suppressed every week, they belong on the list of alerts to fix, not the list to mute.
Where ITOC360 fits
ITOC360 gives teams one place to suppress alerts from every monitoring tool, so maintenance doesn't page anyone and real problems still do:
One suppression for every source. ITOC360 Alerting receives alerts from 50+ monitoring tools, so a maintenance window is set once, not separately in Prometheus, Datadog and Zabbix.
Scoped, time-limited windows. Maintenance windows are scoped to services and expire automatically.
Suppressed, not lost. Alerts that arrive during a window are recorded with the rest of the incident timeline, so the review can see exactly what fired.
Noise reduction that runs all the time. Deduplication and correlation group the real problems that remain, so the alert that does page during a window arrives as one incident with context.
Customers kept informed. Planned maintenance can be announced on ITOC360 Status Pages.
Frequently asked questions
What is alert suppression?
Alert suppression is the deliberate, time-limited blocking of notifications for specific alerts or systems. Monitoring keeps evaluating and recording alerts, but nobody is paged while the suppression is active. It's most often used during planned maintenance.
What is a maintenance window in monitoring?
A maintenance window is a scheduled period of planned work on specific systems, with a defined scope, owner, start and end time. During the window, alerts the work is expected to cause are suppressed so they don't page on-call engineers.
What is the difference between alert suppression and acknowledgment?
Suppression stops notifications before anyone is paged, usually for expected events. Acknowledgment happens after a page: it records that someone owns the alert and stops further escalation, but the alert itself stays active.
What is the difference between suppression and deduplication?
Deduplication merges repeated copies of the same alert into one, and runs all the time. Suppression blocks notifications for a defined scope and period. Deduplication reduces noise from real problems; suppression reduces noise from expected events.
Should alerts still be evaluated during a maintenance window?
Yes. Keep alerts evaluating and recording, and block only notifications. That preserves history for the review and means anything still firing when the window ends notifies immediately.
Which alerts should never be suppressed?
User-facing synthetic checks and SLO burn-rate alerts, alerts for systems outside the maintenance scope, security alerts, data integrity and backup alerts, and capacity limits such as disk-full or certificate expiry.
How long should a maintenance window be?
As long as the planned work plus a small buffer, often around 15 minutes. It should have an automatic end time. If the work overruns, extend the window deliberately and record why, rather than leaving it open-ended.
What is alert inhibition?
Inhibition is a rule that mutes alerts caused by another, higher-priority alert. For example, a "database down" alert inhibits the dozens of "API can't reach database" alerts that follow it, so responders see the cause instead of the symptoms.
Sources
Prometheus documentation: Alertmanager (silences, inhibition, time intervals)