Skip to content

Alerts

The alerts screen is the operational hub for incident awareness — a real-time queue of triggered alerts, the set of rules that generate them, and the tools for acknowledgement and triage. It covers both the alert queue tab (/projects/:id/alerts) and the rules tab (/projects/:id/rules).

Alert queue with severity badges

Every alert carries a severity level that determines its visual prominence and notification behaviour:

CriticalWarningOffline
Severity Meaning Example
Critical Immediate risk to infrastructure or safety; triggers highest-priority notification Reservoir level below dead storage
Warning Anomalous reading approaching threshold; triggers standard notification Flow rate exceeds design capacity
Offline Sensor has stopped reporting — no telemetry received Staleness exceeds 6× device cadence

You set Critical or Warning on a rule; Offline is raised automatically by the staleness detector (a stale comparator), not chosen by hand.

The queue is a real-time feed of every alert that has fired, ordered by recency. Each row shows the severity badge, alert title, affected asset/sensor, time since trigger, and acknowledgement status. The scrubber widget filters by “all / active / acknowledged”.

Click any row to expand an alert detail panel showing the triggering condition, the metric value that breached the threshold (with a sparkline of the 24-hour lead-up), the rule definition, and the acknowledgement history with timestamps.

Alerts don’t just wait in the in-app queue — when a rule opens an alert, Nereus also emails the team. The notification names the rule, the affected asset, the value that breached and the threshold it crossed, the severity, and the local time it triggered (in your organisation’s time zone, never a bare UTC time), with a link straight to this screen.

Who gets emailed: every active member of the organisation whose role is Operator or above — Operators, Engineers, Admins, and Owners. Viewers can watch the queue but are not paged. The list is deduplicated by email address, so a member with several grants is emailed once.

This is a single organisation-wide rule today: there is no per-user or per-alert opt-in, and no settings toggle to subscribe or mute — so don’t go hunting for one. Being paged is a consequence of holding an Operator-or-above role. Per-user notification preferences (choosing which alerts reach you, and over which channel) are a planned future capability, not a shipped feature.

Emailed to Operator+Emailed to Operator+

Switch to the Rules tab to see every alert rule configured for the project.

Alert rule list

Each rule row shows the rule name, condition summary (e.g. “level_m falls below 0.5 m (×2)”), target scope (an asset, a class, or a group), and whether it’s active or paused. The scrubber toggles between “all / active / paused”.

Click Create rule or edit an existing rule to open the rule editor — a sentence-style form in four sections:

  1. Target — what it watches: an asset, an asset class, or a group.
  2. Condition — the metric, comparator, and threshold (e.g. “Alert when level_m falls below 0.5 m”).
  3. Reduce false alarms — the debounce count and an optional clear value (hysteresis).
  4. Classification — the severity (Warning or Critical) and a category label.

The debounce confirms the condition over N consecutive readings before opening, so transient blips don’t trigger false alarms. The optional clear value governs resolution — the metric must recover past it before the alert clears (it defaults to the trip value when omitted).

Acknowledge — click Acknowledge on any alert row to mark it as seen. Acknowledged alerts stay in the queue but are dimmed. Acknowledge notes are optional and visible on the detail panel.

Create rule — opens the rule editor form. Rules are active immediately on save unless the Paused toggle is set.

Edit / pause / delete rule — from the rule row’s overflow menu. Pausing a rule keeps its configuration but stops it from firing (and any existing alerts from it remain active). Deleting a rule removes it permanently; existing alerts stay in the queue with the rule annotated as “deleted”.

Bulk acknowledge — select multiple alert rows and click Acknowledge selected.