Alarms

Active and historical system alarms. Alarms are created automatically when built-in rules detect faults (scanner offline, database unreachable, TLS expiring, etc.). Identical events roll into existing open alarms (deduplication). Alarms can be acknowledged, manually resolved, or auto-resolved when the underlying condition clears.

Fields & Columns

Name Description
Severity Alarm severity: critical, high, warning, or info
State Current alarm state: open, acknowledged, or resolved
Entity What the alarm is about — entity_type:entity_id (e.g., scanner:my-scanner-01)
Summary Human-readable description of the fault
Count Number of matching events rolled into this alarm
Age Time since the most recent matching event was received (last bump or initial creation)
First Seen When the alarm was first created

How To

Acknowledge an alarm

  1. Find the alarm in the table
  2. Click the row actions menu
  3. Select "Acknowledge"
  4. The alarm state changes to "acknowledged" — it stays visible but is no longer "open"

Resolve an alarm manually

  1. Find the alarm in the table
  2. Click the row actions menu
  3. Select "Resolve"
  4. The alarm state changes to "resolved"

Filter alarms by severity

  1. Navigate to Health > Alerting > Alarms.
  2. Use the severity column filter dropdown.
  3. Select the severity levels to display (e.g., critical, high).
  4. The table updates to show only matching alarms.

Gotchas

  1. Auto-resolved alarms are resolved by the system when the OK event arrives (e.g., scanner_up resolves scanner_down).
  2. Disabling a rule under Alarm Rules prevents new alarms of that type but does not resolve existing ones.
  3. Alarms are deduplicated by alarm_key (rule:entity_type:entity_id). Repeated events bump the count, not create new alarms.

API Calls (5)

Method Path Description
GET /api/health/alerting/alarms List alarms with optional filters (state, severity, entityType)
GET /api/health/alerting/alarms/count Active alarm counts for nav badge
GET /api/health/alerting/alarms/:id Alarm detail with matching event timeline
POST /api/health/alerting/alarms/:id/acknowledge Acknowledge an open alarm
POST /api/health/alerting/alarms/:id/resolve Manually resolve an alarm

Related Pages

  • Events — Events are the raw fault records that create alarms
  • Alarm Rules — Rules define which events create alarms and at what severity
  • Notification Channels — Channels deliver alarm state change notifications to external services
  • Notification Policies — Policies control which alarm transitions trigger notifications
  • Notification Log — Log shows delivery history for alarm notifications
  • Overview — Architecture diagram shows overall system health
  • Sessions — Session IP spread alarms link to session investigation