IoT Device Offline Alarm

Who it’s for

Operators of IoT fleets and on-call engineers asking “has this device dropped off the network?”, “is this LoRaWAN endpoint losing carrier coverage?”, “did this asset tracker run out of battery — or was it stolen?” — when short blips should pass quietly but a sustained silence deserves an early warning and a critical escalation.

What it does

Reads the device’s built-in active attribute and raises a Major alarm when the device stops reporting for several minutes, escalating to Critical if it stays disconnected longer. The alarm clears the moment the device reconnects.

How to set up

The rule has default values for every threshold, so it works as soon as it is installed. Install on a device profile so every device of that type is monitored and any new device added later is picked up automatically. Single-device installs are also supported.

The active attribute is set by ThingsBoard’s device-profile inactivity rule, which flips it to false after 10 minutes of silence by default. Out of the box the timing chain is: device stops reporting → 10 min platform timeout → 15 min rule hold → Major fires (≈ 25 min total). For devices with a non-default reporting cadence, tune the inactivity timeout on the device profile or per device.

By default the rule reads active as a server-side attribute. If your ThingsBoard server stores the active flag as telemetry instead of attributes, switch the state argument’s Argument type from Attribute to Latest telemetry before installing — the key stays active.

How to customize

• To use different duration attribute names — change the Attribute key on the warningMinutes and criticalMinutes arguments to match what your devices already use (e.g. inactivityWarningMinutes → offlineGraceMinutes).
• To change the inactivity tolerance used when no per-entity attribute is set — change the Default value on the warningMinutes and criticalMinutes arguments.
• To tune the inactivity tolerance at runtime without editing the rule — set the duration as a regular server-side attribute on the entity. It can be edited directly from a dashboard using Update Multiple Attributes input widget:
  • Per device — set the duration attribute (e.g. inactivityWarningMinutes) on the device itself. The per-entity value overrides the Default value.
  • Per customer (in deployments that use customers) — change Entity type on the duration argument to Current owner, then set the duration attribute on the customer. Every device that customer owns picks up that value.
  • Tenant-wide — change Entity type to Current tenant, then set the duration attribute on the tenant. The value applies across every device.
• To make the alarm manual-clear-only — remove the Clear condition. The alarm then stays active until an operator clears it, even after the device reconnects.
• To restrict firing to expected reporting hours — in the Trigger condition’s Schedule, choose Active at a specific time range (or Custom schedule for different intervals per day) — useful when devices are expected to be silent overnight or on weekends. For per-entity schedules — devices with different reporting cadences — switch to Dynamic mode and source the schedule JSON from an attribute on the entity.
• To control where the alarm shows up — toggle the propagation flags under Advanced settings.

See also

When you need to detect that a single telemetry stream on a multi-sensor device has gone silent (rather than the entire device), use the alarm template that watches one telemetry key for freshness instead:

Sensor Stopped Reporting Alarm verified Dmytro Shvaika