Alerts

The bell in the top bar and the Alerts page show the same alerts. The bell is a preview; the page is where the work happens.

The bell

The panel shows the most recent alerts, grouped, each with one action — and the link at its foot goes to the page. It is deliberately a preview rather than a shortcut: navigating away abandons whatever the user was doing in order to answer "is this worth my attention?", which the panel answers in two seconds.

Every row carries Why me. Without it, an alert inbox in a multi-user product reads as spam within a week.

The counter on the bell respects the severity floor the user chose for themselves. A counter that is never zero is decoration.

The queue

The page opens on Needs action, never on everything. The strip at the top is a filter and a count in the same click.

Lane	What is in it
Needs action	Firing, and nobody has taken ownership yet
Acknowledgment expired or expiring	Somebody took ownership and the time ran out
In progress	Acknowledged and in force — there is an owner and a date
Snoozed	"Not now" — they come back on their own at the chosen time
Closed	The condition resolved, or they were closed by hand

On a vulnerability or capacity row, the first action is Schedule a patch window: it opens the scheduling wizard with the details filled in, and the event it creates is linked back to the alert. Triage that produces progress rather than dismissal is the whole difference.

The page is the product's ordinary table — sorting, column filters, the quick-filter rail, saved views and export, exactly as on the host list.

Alert rules

An administrator defines rules in settings, under Alert rules and delivery. A rule is built in three steps.

What is checked — a data source and conditions. The sources are the server inventory, CVE vulnerabilities, events, capacity clusters, and maintenance windows on virtualization hosts. You can require all conditions to hold, or at least one.

When to alert — severity, a match threshold ("alert when at least N rows match"), an evaluation frequency, and a mute between alerts: even while the conditions keep holding, no further alert is sent until the chosen interval has passed.

Where it is sent — the channels.

A rule with no channels is still evaluated and still recorded in the log — it simply sends nothing.

Testing

Test run evaluates against live data and sends nothing. Test send to the channels really sends, and marks the send as a test. Both run against the saved version of the rule, and the screen says so when there are unsaved changes.

Delivery channels

A channel is an integration connection that is already configured. The Delivery channels screen shows which connections are available as a channel, what state they are in and which rules are attached to them; the connection itself is edited in the integrations catalog, and attaching one to a rule happens inside the rule editor. A disabled connection is marked as such — sending to it will fail until it is enabled.

The Delivery log records every delivery — real or test — with the time, the rule, the channel, the outcome and the number of matches.

The bell's thresholds

A separate screen decides which open vulnerabilities reach the bell: a minimum severity, and a look-back window in days — a vulnerability added longer ago than that does not alert. The change takes effect immediately, with no server restart.

Deletion

Deleting a rule is immediate and also removes its delivery history from the log. To stop the alerts without losing the rule, disable it.