Rules & alerts
Rules are visual trigger → condition → action flows. When a trigger fires and the conditions pass, every connected action runs.
Triggers
| Trigger | Fires when | Key options |
|---|---|---|
telemetry | A metric crosses a threshold | metric, comparison (>, <, …), value, and for_seconds — the condition must hold that long before firing (debounces noisy sensors). |
status | A device changes status | target status (online / offline); scope to a device type or specific devices. |
schedule | A cron expression matches | cron in your org's timezone (Settings → Org timezone), evaluated at minute granularity. |
Conditions
Optional expression nodes between trigger and actions. All clauses must pass (value > 30, comparisons against the triggering metric, device fields, and constants). Use them to narrow a broad trigger — for example only alert for devices tagged production.
Actions
| Action | What it does |
|---|---|
alert | Opens an alert in the Alerts page with severity (info / warning / critical), templated title and body. |
command | Sends a command to a device (e.g. set_lamp {on: true}) — closes the loop from sensing to actuation. |
webhook | POSTs a templated JSON body to your URL — Slack, PagerDuty, or your own service. |
email | Sends a templated email to the addresses you list. Requires an email provider key (RESEND_API_KEY); until one is configured the action is recorded in the rule run but not delivered. |
delay | Waits N seconds before running the actions after it. |
Templates support variables like {{rule.name}}, {{device.name}}, {{metric}}, {{value}}, and {{ts}}.
Cooldown & debounce
- Cooldown (
cooldown_s, per rule): after firing, the rule stays quiet for this long — prevents alert storms from a flapping sensor. - for_seconds (telemetry trigger): the threshold must hold continuously for this long before the rule fires at all.
Tips
- New rules start disabled — build the flow, then flip the switch.
- Every run is recorded with its trigger payload and per-action results — check the rule's run history when debugging.
- Start with one high-value rule: "alert me when anything goes
offline" catches most fleet problems.