Silences and maintenance windows

aiAxonIQ has two ways to keep alerts quiet, under Govern → Alerts. They look similar and do very different things, and choosing the wrong one is the most common way to lose information you later need.

​

Silences

A silence is checked by the alerting loop before a rule is allowed to fire. While a silence covers a rule, that rule does not move to firing: nothing is written to alert history, no incident opens, no notification is sent, and nothing afterwards records what happened while the silence was in force.

​

What a silence matches

A silence has a name, a start and an end, and a scope made of rules, matchers, or both: How they combine:

• Every field you fill in must match (AND, not OR). Within one field, any of the values you select matches. So Severity = HIGH or CRITICAL plus Signal = logs silences only high and critical log alerts.
• An empty field constrains nothing.
• A silence must name at least one rule or one matcher. One that names neither would silence every alert in the account, and it is refused.
• Only these three matchers exist. Service names and labels cannot be matched — an alert rule carries neither — and the API refuses them rather than storing a matcher that would never apply.
• A silence that names an alert type never matches a security detection or a synthetic check, because those have no alert type.

​

Beyond alert rules

A silence with no rules named — matchers only — also withholds notifications from security detections and synthetic checks whose severity and signal match. For those producers the silence works like a maintenance window does: the detection or check result is still recorded and only the notification is withheld.

​

Timing and editing

A silence is in force from its start to its end, both inclusive. There is no enable switch — to end a silence early, edit its end time or delete it. Editing a silence changes it in place. It is never briefly removed, so extending a silence during an incident cannot let the rule page you in between.

​

Maintenance windows

A maintenance window withholds notifications and nothing else. Rules keep evaluating, incidents keep opening and alert history keeps being written. Each notification the window holds back is recorded as withheld, naming the window that withheld it, and — for alert-rule incidents — appears on the incident’s timeline as Notification withheld.

​

What a window matches

As with silences, every field you fill in must match and an empty field means “all”. A window with nothing selected withholds every notification in the account — which is valid and sometimes what you want, and the form warns you because nothing else will.

​

Scheduling

• A window has a start and an end, and may be at most 30 days long.
• Boundaries are half-open: an event at exactly the end instant is outside the window, so a window ending at 03:00 and one starting at 03:00 do not overlap.
• Windows may overlap. A notification covered by two windows is withheld once, and the one reported is whichever ends last — because the next question is when paging resumes.
• A window has an Enabled switch. A disabled window withholds nothing, whatever its dates say.
• There is no recurrence rule. For regular maintenance, keep a disabled window and edit its dates each time.

​

When a window ends

When a window ends, is disabled, or is deleted, aiAxonIQ looks at what it withheld:

• Alert-rule incident still open — the problem is still happening after the work finished. The withheld notification is sent, once.
• Alert-rule incident resolved during the window — the problem healed. The notification is never sent.
• Security or synthetic notifications stay withheld. Those incidents never resolve on their own, so “still open” would mean “nobody has closed it yet” rather than “still broken” — replaying them would page for every detection raised during the window. Their incidents remain open in the Incidents list.

A released notification is held again if another window or a silence covers it at that moment, and goes out as soon as nothing does.

​

How they interact with everything else

• Escalation respects both. An escalation page is an ordinary notification, so a window or silence that covers it withholds it. Escalation is not an override. See Escalation policies.
• The Test action is not withheld. Testing a rule or a channel is a person asking for a message, so a maintenance window does not block it — otherwise the button would look broken exactly when you are preparing for a deploy.
• A failed lookup delivers. If aiAxonIQ cannot check your maintenance windows at delivery time, the notification is sent rather than silently dropped: an unwanted page during a deploy is better than a missed page during an outage.
• Changes are audited. Creating, editing and deleting silences, and creating and editing maintenance windows, are recorded in the Audit log.

​

Create a maintenance window

Creating a silence is the same shape under Alerts → Silences: name, start, end, then rules and/or matchers.

​

Verify it works

• Maintenance window: during the window, trip a covered rule. The rule should fire and an incident should open under Incidents, but no notification arrives, and the incident’s timeline shows Notification withheld with reason maintenance.
• Silence: while it is in force, trip a covered rule. No incident opens and nothing is added to the rule’s history. After the silence ends, the rule fires on its next evaluation if it is still breaching.

​

Troubleshooting

​

Next