Events page

The Events page is the triage screen: one line per monitor that is currently in a non-OK state, across every probe and every Integrator, with the root-cause analysis folded in so a single outage reads as one incident instead of a dozen alerts.

Open it from the left navigation, or go straight to /web/html/layout.html#/events.

Where the data comes from

The Webserver stores no events of its own. Each request to /events fans out in parallel to every enabled Integrator, asks each one for its current event list, and merges the answers into a single table.

Three things follow from that design:

The page refreshes itself every 30 seconds. Background ticks are skipped while the browser tab is hidden — the refresh fans out to every Integrator and rebuilds the whole table, which is not worth doing for a tab nobody is looking at. The refresh button forces an immediate reload.

Reading the table

Rows are sorted newest first by default. Click any header to re-sort; the Actions column is not sortable.

Statuses

Statuses are ordered by severity in the summary panel and in the status filter:

CRITICAL, ERROR, MAJOR, MINOR, EXCEPTION, TIMEOUT and CONFIG are the problem statuses — the ones the Problems chip selects.

The two views

The segmented control in the toolbar switches between two populations that are never mixed:

They are separate on purpose. An application rollup is a status the Webserver recomputes from its members, not something that happened: inside the stream it would restate rows already on the page, and being outside the causal model it can never be a root or a symptom.

Filtering

Filters stack: each one narrows what the previous ones left.

Hide OK

A switch in the toolbar, on by default — the page is for things that need attention. Turn it off to see recovered monitors in the same list.

Status summary chips

The panel above the table counts the population by status and doubles as a filter.

• Click a status chip to filter to it; click the active one again to clear.
• The Problems chip selects every problem status present at once.
• The clear chip drops the status filter.
• The meter segments under the headline are clickable too, and answer to Enter and Space from the keyboard.

The chips and the Status column filter are the same filter shown twice — driving either one repaints the other, so they can never disagree.

The counts are taken over everything the view chooser and an isolated incident have left on the table — not over what Hide OK and the column filters removed. A chip that hid its own count would be unreadable.

Column filters

The second header row filters per column:

The RCA dropdown offers a fixed vocabulary — root, symptom, independent — and matches on the row’s role rather than on the rendered text, which carries per-row counts and deltas.

Clear all filters

The filter-circle-xmark button in the toolbar resets everything at once: Hide OK off, back to the all-monitors view, incident isolation cleared, every column filter emptied.

Root-cause analysis

When at least one enabled Integrator runs the correlation engine, the page grows an RCA column and an incident strip. Both are hidden entirely when no Integrator has correlation on — an always-empty column would just be noise on the setups that never turned it on.

The correlation itself is computed by the Integrator, not by the Webserver. The rules — which types can explain which, how a candidate proves it concerns the same host and the same service, and how the look-back window works — are documented in Integrator, correlation engine.

The incident strip

The strip headlines the ratio the feature exists for:

24 events → 9 incidents          15 correlated as symptoms

Then one chip per incident, newest first, each carrying the cause’s type/metric, its probe, and how many events it explains. Two icons qualify a chip:

When nothing correlated, the strip says so plainly rather than disappearing.

The RCA column

Hover any RCA cell for the full sentence: which monitor is the cause, how the link was established, and what remains unverified. The wording is deliberate — it says “Root cause” only where the evidence is direct (the monitor was provisioned from that Sentinel Agent’s own configuration, or the vanished process owned the very port the check connects to), and “Possible root cause” everywhere else. A symptom whose link is unconfirmed is styled weaker and carries a question-mark icon.

Isolating an incident

Click an incident chip, or any RCA cell in the table, to isolate that incident: the root and everything it explains stay, everything else drops away. Click again to clear.

Inside an isolated incident the table re-sorts oldest-first, because causal order is the useful reading order — the root broke first, so it reads at the top followed by what it took down.

Two behaviours are worth knowing:

• Isolating an incident while the Applications view is active switches back to the event stream. Rollups are never part of the causal graph, so an isolated incident would filter down to nothing. The control moves visibly rather than doing it behind your back.
• If the isolated incident disappears from a refresh — recovered, or filtered out by a tag change — the isolation is dropped instead of silently hiding every row.

Row actions

Actions depend on the event’s monitor type.

When the page is empty

Translations

• fr: Page Events