Alert rules

An alert rule watches one decoded metric (or hardware event) and fires when it breaches a condition. Rules are evaluated live, off the ingest path: as the decode worker emits each reading, the alert worker checks it against your rules and, on a breach, records an event and notifies your channels.

Start from a template

The Alert rules screen offers ready-made rules for common failure modes — heap critically low, heap leaking fast, low battery, CPU pegged, stack nearly exhausted, hard fault, watchdog reset, high temperature. Pick one and it fills the form with a sensible metric, operator, threshold, and severity; adjust anything, add a notification channel, and save. The template metrics match the payload-rule templates, so a device set up from a template already emits what they watch.

What a rule is made of

Create and manage rules on the Alert rules screen. Each rule has:

1. Metric — the name of a decoded metric (e.g. heap_free) or a hardware event (e.g. hardfault). An event is evaluated as the value 1 when it occurs, so you can alert on its presence.
2. Kind — threshold compares the latest value; rate compares how fast the value is changing.
3. Operator + threshold — gt, lt, gte, lte, or eq, compared against your number.
4. Scope — a specific fleet, or org-wide (all fleets) when no fleet is set.
5. Window — for a rate rule, the span the rate-of-change is measured over; it also sets the per-rule cooldown (see below).
6. Severity — info, warning, or critical, carried into the recorded event and notifications.
7. Channels — where a breach is sent: email, webhook, or slack (each with a target). Webhooks always POST; email sends only when SMTP is configured. Use Send test to fire a one-off message and confirm the channel is wired up before you rely on it.

Threshold vs. rate

A threshold rule fires when the most recent reading satisfies value <operator> threshold. A rate rule fires on the per-minute change of the metric across the window — useful for catching a fast drain or spike before it hits an absolute limit.

# "heap is critically low"      →  threshold, heap_free  lt  8000
# "heap is leaking fast"        →  rate,      heap_free  lt  -500   (dropping >500/min)
# "a hard fault occurred"       →  threshold, hardfault  gte 1

When a rule fires

On a breach the worker records an alert event — shown in the device's Crash / interrupt log and in the Recent alerts feed on the Alert rules screen (an org-wide, newest-first list of what has been firing) — and sends every channel. A per-rule cooldown equal to the window suppresses repeat firings inside that span, so a sustained breach notifies once, not on every frame.

Escalation

A rule can add escalate after N minutes with its own escalation channels. If a breach episode stays active longer than N minutes, the escalation channels fire exactly once for that episode — e.g. notify the on-call webhook only when a warning has persisted, not the moment it appears.

Rules evaluate the decoded stream, so a metric only alerts once your active payload rule produces it — see Payload rules. Toggle a rule off with its enabled switch; disabled rules are kept but never fire. A fired alert can also trigger an autonomous investigation on the Enterprise tier — see the agent.