The first monitoring dashboard most IoT teams build shows a number: devices online. It feels reassuring and it is nearly useless on its own. A device can be connected and sending garbage, connected and about to run out of battery, or connected only because it reboots every ten minutes. Online is the weakest form of healthy.

Think in Layers

It helps to monitor at three levels and to know which question each one answers.

The device. Is the hardware and firmware in good shape? Battery or supply voltage, temperature, free memory, storage use, uptime since last reboot, and the firmware version running.

The connection. Is the device talking reliably? Signal strength where relevant, reconnect count, time since last message, and failed publish or request counts.

The data. Is what arrives plausible? Reporting interval versus expected, gaps, values outside physical limits, and timestamp drift.

A fleet can be fine on one layer and broken on another. Most real incidents show up first as a pattern across layers, such as a rise in reconnects followed by data gaps.

Heartbeats Done Properly

A heartbeat is a small periodic message that says “I am alive and here is my basic condition”. It is worth having even when devices already send telemetry, because telemetry may legitimately go quiet when nothing is happening.

Include a few diagnostics in it: uptime, firmware version, reset reason, and a couple of resource readings. The reset reason is underrated. A device that reports watchdog resets repeatedly is telling you something no connectivity metric will.

Decide how many missed heartbeats count as offline. One missed message is noise on a mobile network. Several in a row is a signal. Make this threshold per device class, since a device that reports every minute and one that reports daily need different tolerances.

Trends Beat Thresholds

Static thresholds such as “alert if battery is under a set level” catch only the last stage of a problem. Trend-based checks catch the slope. A battery that is dropping faster than its peers tells you about a firmware change, a bad batch or a harsh environment weeks before it hits empty.

The same applies to reconnect counts and message latency. Compare devices to their own history and to similar devices, and flag the outliers. This works even when you do not know what “normal” should be in absolute terms.

Aggregate Before You Alert

Alerting on individual devices at fleet scale produces pages nobody reads. Alert on groups: a region, a hardware revision, a firmware version, a network provider. If forty devices on the same firmware version start resetting after an update, that is one incident, not forty.

Reserve per-device alerts for devices where a single failure matters, such as safety equipment or a high-value installation. For everything else, use per-device views for investigation and group-level rules for paging.

A Starter Signal Set

Signal	Layer	What it helps catch
Time since last message	Connection	Devices gone quiet
Reconnect count over a window	Connection	Unstable links or session conflicts
Reset reason and uptime	Device	Crashes, watchdog resets, power faults
Battery or supply trend	Device	Premature drain, bad batches
Firmware version distribution	Device	Stalled updates, drift across the fleet
Reporting interval versus expected	Data	Throttled or misconfigured devices
Out-of-range or frozen values	Data	Sensor failure, stuck readings

You do not need all of these on day one. Start with the first three and add the rest as your incidents teach you what you missed.

A Hypothetical Example

Suppose a fleet of cold-chain loggers is all showing online, yet the operations team keeps finding gaps in temperature records. Looking at heartbeat data, the team sees that one hardware revision has a reconnect count many times higher than others, and its reset reason is frequently a brown-out. Cross-referencing against battery trends shows the affected units are the ones in colder locations. Online status never flagged any of it, because each device reconnected before the next check.

The fix involved a firmware change to reduce radio activity at low voltage. The monitoring that found it was nothing exotic, just reset reasons and reconnect counts grouped by hardware revision.

Common Traps

One is monitoring only what the platform gives you for free. Built-in connection status is a start, but device-level diagnostics have to be designed into the firmware, and adding them later means another update across the fleet.

Another is high-frequency diagnostics that cost more in bandwidth, battery or cloud ingestion than the problems they detect. Send diagnostics less often than telemetry and make the interval remotely adjustable, so you can raise it for a misbehaving group.

A third is alert fatigue. If an alert fires every day and nobody acts, delete it or fix its threshold. Alerts nobody acts on train people to ignore the one that matters.

Frequently Asked Questions

How often should devices send heartbeats? Often enough to detect failure within the time your operations can tolerate, and no more. Battery and data costs push toward longer intervals, so tie the choice to how quickly you need to know.

Should heartbeats be separate from telemetry? Usually yes, or at least include a distinct diagnostics block. Telemetry can legitimately pause, and a separate heartbeat tells you the difference between quiet and gone.

What is the single most useful diagnostic field? Many practitioners would say reset reason, since it explains instability that connectivity metrics hide. It costs almost nothing to include.

Can I rely on the cloud platform’s built-in monitoring? Partly. Connection status and message counts are useful, but you still need device-level health signals and group-level rules that match your fleet.

How do I avoid alert noise? Alert on groups and trends, tune thresholds from real incidents, and review which alerts led to action each month.

Next Step

Open your current dashboard and list every device-level field your firmware reports today. If reset reason, uptime and firmware version are missing, add them to the next firmware release as a small, deliberate change.