An alarm in Kudzu Canopy NOC is a threshold rule attached to a metric. When a computed KPI crosses the configured boundary, the alarm fires and the platform records the event, updates the live state, and routes notifications. Alarms turn raw metric values into operational state that you can monitor, investigate, and respond to.
Metrics alone tell you the current value of a KPI, but they do not tell you whether that value is acceptable. Alarms provide the boundary: they define what “normal” looks like and what counts as a warning or a critical condition. Without alarms, you would need to manually watch every metric and decide when to act. With alarms, the platform does that evaluation continuously and notifies you when something needs attention.
An alarm is a threshold rule tied to a specific metric. A single metric can have multiple alarms, each representing a different severity level. For example, a “silent devices” metric might have a warning alarm at 5 devices and a critical alarm at 20 devices.
Each alarm specifies:
Criticality levels define the operational importance of an alarm. Each level has three properties:
| Property | Description |
|---|---|
| Name | A human-readable label (for example: Notice, Warning, Critical). |
| Color | A visual indicator used in the UI for badges, charts, and status banners. |
| Weight | A numeric value from 0 to 100 that determines priority. Higher weight means higher importance. |
The weight determines how the platform prioritizes alarms:
When multiple alarms fire for the same metric, the highest-weight alarm becomes the live state for that metric.
The alarm lifecycle follows five stages:
┌─────────────────────────────────────────────────────────┐
│ 1. EMIT Analysis algorithm produces a metric │
│ 2. COMPARE Platform checks metric against │
│ configured alarm thresholds │
│ 3. FIRE Highest-weight crossing alarm becomes │
│ the live state for the metric │
│ 4. RECORD Platform logs state change to alarm │
│ history (raise, resolve, escalate, │
│ de-escalate) │
│ 5. NOTIFY Users see the result in Monitoring, │
│ Alarms, Overview, Inbox, email, │
│ Discord, and reports │
└─────────────────────────────────────────────────────────┘
State transitions recorded in alarm history include:
A metric is considered flapping when it repeatedly crosses an alarm threshold in a short period — for example, oscillating between “firing” and “resolved” every analysis cycle. Flapping generates noisy notifications that distract from genuine issues.
The platform detects flapping behavior and suppresses instant resolution notifications when it identifies this pattern. The alarm still transitions internally, but the notification system withholds the “resolved” message until the metric stabilizes. This ensures you are notified when a real problem starts but are not flooded with false resolutions.
If you see an alarm marked as flapping, it typically indicates a metric hovering near a threshold boundary. Consider adjusting the threshold, tuning the analysis algorithm parameters, or reviewing the network sensitivity preferences in network settings.
The Alarms view groups active and past alarms by their position in the problem taxonomy. You can see all firing alarms for a particular operational concern at once — for example, all alarms under “Coverage & RF Quality” — and drill into individual metric detail pages that show history charts and entity references.