> ## Documentation Index
> Fetch the complete documentation index at: https://docs.aiaxoniq.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Silences and maintenance windows
> The two ways to stop aiAxonIQ paging you: a silence stops a rule firing, a maintenance window keeps alerting on and withholds only the notification.
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.
| | **Silence** | **Maintenance window** |
| :---------------------------- | :-------------------- | :-------------------------------------------------------- |
| Where | **Alerts → Silences** | **Alerts → Maintenance windows** |
| Stops the alert rule firing | **Yes** | No — rules keep evaluating and firing |
| Alert history written | No | Yes |
| Incident opened | No | Yes |
| Notification sent | No | No — recorded as *withheld* |
| Record of what happened | **None** | Every withheld notification, and which window withheld it |
| Pages still owed when it ends | Nothing is sent | Sent once, for alert rules whose incident is still open |
**Use a maintenance window for planned work** — a deploy, a failover, a
migration. Afterwards you can still ask *what broke while nobody was being
paged?*, and anything still broken when the window ends pages you then.
**Use a silence for a rule that is simply noise** and you do not want a
record of it firing at all.
**Reading silences and windows needs any role. Creating, editing and
deleting them needs the Editor role or higher.** Auditor is deliberately
excluded: an auditor reads what was suppressed and does not get to widen it.
See [Roles and permissions](/concepts/roles).
## 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:
| Field | Matches |
| :------------- | :------------------------------------------------------------------------------------------------------------ |
| **Rules** | The named alert rules. Leave empty to rely on matchers alone. |
| **Severity** | The alert's severity: `LOW`, `MEDIUM`, `HIGH`, `CRITICAL`. |
| **Signal** | The telemetry the rule watches: `metrics`, `logs`, `traces`, `synthetics`, `security`. |
| **Alert type** | `THRESHOLD`, `ABSENCE`, `COMPOSITE`, `SLO_BURN_RATE`, `ANOMALY`, `SYNTHETIC`, `GOVERNANCE`. Alert rules only. |
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.
**When a silence ends, nothing is replayed.** A rule that is still breaching
simply fires on the next evaluation (subject to its cooldown), as if for the
first time. Anything that happened and cleared while the silence was in force
left no trace.
## 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
| Field | Matches |
| :------------- | :-------------------------------------------------------------------------------------- |
| **Rules** | Notifications from these alert rules. Select none for every rule. |
| **Producers** | Alert rules, security rules, synthetic checks. Select none for all three. |
| **Severities** | `INFO`, `LOW`, `MEDIUM`, `WARNING`, `HIGH`, `CRITICAL`. Select none for every severity. |
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](/guides/alerts/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](/guides/audit).
## Create a maintenance window
Go to **Alerts → Maintenance windows** and choose to create a new window.
Give it a name (and optionally a description of the work), a start and an
end. Leave **Enabled** on.
Choose the rules, producers and severities to cover, or leave them empty to
cover everything.
The window appears in the list, counted under **In force now** or
**Scheduled**.
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
* The window is **disabled**, or its dates do not cover the moment of the
page. Remember the end instant is excluded.
* Its scope does not match: a different rule, producer or severity.
* The window **ended** and the problem was still open — the withheld page
was released, as designed.
* The message was a **Test**, which windows do not withhold.
* It names neither rules nor matchers — refused because it would silence
everything.
* The end is not after the start.
* It uses a matcher other than severity, signal or alert type.
The window is longer than 30 days, its end is not after its start, or a
producer or severity value is outside the lists above.
A silence that names specific rules, or names an alert type, never matches
security detections or synthetic checks. Use a matcher-only silence (severity
and/or signal), or a maintenance window scoped to that producer.
That is the nature of a silence — nothing is recorded. Use a maintenance
window next time if you need the history.
## Next
Who gets paged when nobody acknowledges.
Where withheld notifications show up.
Rule types, conditions and testing.
The channels notifications are delivered to.