Skip to content

Cookie preferences

We use cookies for our own analytics, to see how our campaigns perform and, if you allow it, to load content from other services such as the Google site search. We never sell your data. Necessary cookies keep the site working and cannot be switched off. See our Cookie Policy for details and our Privacy Policy for how we handle personal data.

Security, load balancing and remembering your cookie choice.

Show us which pages people read and how they find the site, so we can improve it (Google Analytics).

Show us which of our ad campaigns bring visitors to the site and remember the campaign or partner link you arrived from (Google Ads, partner program). We do not use these cookies to build advertising profiles.

Load the site search from Google when you use it. Google sets its own cookies and shows ads in the search results.

© 2026 The ThingsBoard Authors
Try for free

ThingsBoard Cloud

Choose your data region

Your data stays in the region you choose, for residency and compliance. No credit card required.

Rather run it yourself? Install on your own servers

Low percentage of active devices per site

  • Alarm Rule
  • 1 install
  • v1.0.0
  • Jul 30, 2026
  • MIT license
  • v4.3+

Raises a Critical alarm on a site when the percentage of its active devices drops below a configurable threshold for a sustained period, and clears automatically once it recovers.

Type
  • Alarm
Category
  • Threshold
  • Connectivity
  • Equipment Health
Use Cases
  • Industrial Automation
  • Smart Building
  • Predictive Maintenance

Who it’s for

Facility and fleet managers and on-call engineers responsible for a whole site’s device population, asking “is this site still reporting?” and “did a chunk of devices go dark overnight?” — a brief blip in a device or two should pass quietly, but a site-wide drop from a failed gateway, network, or power outage deserves attention. It’s the aggregate counterpart to per-device offline alarms: those catch an individual device dying, this catches many going dark at once without one alarm per device, and it’s most useful on sites with enough devices for a percentage to be meaningful.

What it does

Reads two time-series keys on the target entity — activeDeviceCount and totalDevicesCount — and raises a Critical alarm when their ratio drops below a configurable threshold for a sustained period. The alarm clears automatically once the ratio recovers for a sustained period.

active-devices-percentage-diagram

How to set up

This rule reads activeDeviceCount and totalDevicesCount. Pair it with the upstream field that counts a site’s devices:

Active Device Count Per Site Dmytro Shvaika

Install this rule on the same “Site” (or similar aggregating) asset that field is installed on, or on its asset profile so every site of that type is covered, including ones added later. Every threshold/duration argument has a default value, so no per-entity setup is required before the rule starts evaluating.

How to customize

  • To change the low-device threshold (default 50%) — set threshold as a server-scope attribute on the entity, or change the Default value on the threshold argument.
  • To change how long the drop must persist before alarming (default 30 minutes) — set alarmMinutes as a server-scope attribute, or change its Default value.
  • To change how long the recovery must persist before auto-clearing (default 10 minutes) — set clearMinutes as a server-scope attribute, or change its Default value.
  • To read the device counts from different telemetry keys — change the Time series key on the activeDeviceCount/totalDevicesCount arguments.
  • To control where the alarm shows up — toggle the propagation flags under Advanced settings.

See also

For a single device or a single feed, pair this site-level rule with:

IoT Device Offline Alarm Dmytro Shvaika Sensor Stopped Reporting Alarm Dmytro Shvaika

Share Your Alarm Rule with the Community

Built a reliable alarm rule? Export it as a JSON from ThingsBoard and publish it to the IoT Hub. Share it with thousands of ThingsBoard developers and help the community react to incidents faster.