Suppression

An alert that never arrived was suppressed for one of the reasons below, and this is the whole list. Seven of them decide whether the notification is created at all; the eighth decides whether a created one is delivered.

Reason	Applied
the incident opened inside a maintenance window	on create, permanently — see below
the incident is snoozed	on create, while the snooze lasts
the policy is muted	on create, while the mute lasts
the service is muted	on create, while the mute lasts
the channel is disabled	on create, and again on delivery
the incident’s severity is below that channel’s min_severity	on create
the send is a resolve all-clear and this channel heard nothing when the incident opened	on create
the policy’s rate limit is exhausted	on delivery

These are the checks behind the alert an incident’s opening, severity change and resolution produce.

Maintenance is the only one that is permanent

A maintenance window is stamped onto the incident at the moment it opens, and that stamp is never looked at again. Two consequences follow, and neither is visible from the row above:

• An incident that opens inside a window is silenced for its whole life, including its resolve, and stays silenced after the window has closed. It does not start alerting when the window ends.
• A window created after an incident opened does not silence that incident. The stamp is taken at open, so declaring a window mid-incident changes nothing about the incident already running.

Every other reason in the table is re-read each time WireWatch decides whether to create the notification. A snooze and a policy or service mute are compared against the clock, so they hold a send back only for as long as they last: once the instant passes, the alert that was held is created and delivered. They defer; a maintenance window discards. What a window covers, when it is active and who may schedule one is on Maintenance windows.

The all-clear only goes where something already went

The resolved all-clear is not sent to a channel that had no notification created for it earlier in that same incident. WireWatch will not tell you something recovered if it never told you it broke.

The commonest way to meet this is to add a channel to a policy while an incident is already open: it was not on the policy when the incident opened, so it received nothing then, and it is not sent the all-clear when the incident closes. The same applies to a channel whose min_severity filtered the opening alert out — having been spared the alert, it is spared the recovery too. Both are normal, and neither is retried: the next incident reaches the channel from its opening event onwards.

Escalation re-checks all of them

Reaching level 2 or above of a policy does not skip the list above — it runs it again, before it sends anything:

Escalation re-applies maintenance, the snooze, a policy mute, a service mute and min_severity.

It also re-checks that the incident is still open and neither acknowledged nor resolved. A disabled channel still receives nothing, and the rate limit still applies at delivery.

So an incident that has gone quiet stays quiet as the ladder would have climbed: a muted policy does not escalate, and neither does an incident inside a maintenance window. A snooze or a mute pauses the ladder rather than letting it run underneath — the delay for the next level is measured from the moment the suppression lapses, not from when the incident opened. A maintenance stamp never lapses, so an incident that opened inside a window never escalates at all.

Rate limit

A policy can cap what it sends: a maximum number of notifications, and a rolling window in minutes that defaults to 60. Once that many have already been sent for the policy within the window, the next one is dropped rather than queued — it is not delivered late and it is not retried. Leaving the maximum unset means unlimited, which is what a policy has until you set one.

The cap is measured against the policy a monitor or its service names. A policy that is in force only because it is the organisation default is not capped, whatever maximum it carries.

Mute

Muting a policy or a service is an instant in time rather than a switch — it is the moment sending resumes. Nothing has to be un-muted afterwards.

A mute holds sends back rather than discarding them. An alert suppressed by a mute is created once the mute lapses, so expect it to arrive late rather than not at all. If you want an incident silenced for good, that is what a maintenance window does.