A fleet dashboard is usually the first screen a client opens in the morning and the last one an engineer checks before a release. Yet most of them open on a map full of pins or a wall of time-series charts, and neither answers the question the person is actually asking: is my fleet healthy, and if not, where do I look?

This post is for founders, product managers and engineers building connected devices who are about to specify their first dashboard. We describe the five numbers we put above the fold, how we define each one so it cannot quietly mislead, and what we push further down the page.

Why most fleet dashboard screens get ignored

Dashboards tend to be built from whatever data is easiest to plot. The device sends temperature, so there is a temperature chart. After a few sprints the screen is busy, and nobody can tell at a glance whether anything is wrong.

The fix is to start from decisions rather than data. Every number above the fold should prompt a clear action when it moves: open a support ticket, pause a rollout, order replacement batteries, call the installer. If a number never changes what anyone does, it belongs on a detail page.

The five numbers we put above the fold

Whether the product is a battery-powered sensor or a mains-powered controller, the same five questions come up. Each gets one tile, one number and one comparison.

Devices reporting on schedule — how many devices have been heard from within their expected interval.
Devices needing attention — how many have an open fault or alert that someone should act on.
Power health — how many devices are below a battery or supply threshold, or projected to cross it soon.
Data completeness — the share of expected readings that actually arrived in the last 24 hours.
Firmware status — how much of the fleet is on the current release, and whether a rollout is in progress.

Everything else is one click away. The hard part is getting the definitions right.

1. Devices reporting on schedule

“Online” is a misleading word for most IoT devices. A LoRaWAN sensor that uplinks every 15 minutes is never online in the TCP sense, and a BLE device that syncs through a phone may be silent for a day by design. What matters is whether each device has been heard from within its own expected interval.

We store an expected reporting interval per device (or per device class) and count a device as late when it misses roughly two to three intervals. One missed uplink is noise, especially on LoRa, where some packet loss is normal and depends heavily on range and gateway coverage. The tile shows “412 of 430 on schedule”, not a percentage alone, because 96% hides the fact that 18 real devices are silent.

2. Devices needing attention

This is the count of devices with an open, actionable fault: a sensor reading out of its physical range, a tamper switch, a stuck relay, repeated watchdog resets. The word that matters is actionable. If an alert fires every day and nobody acts on it, it trains people to ignore the tile.

We separate faults the device reports about itself from threshold alerts on what it measures. A cold room at 9 °C is a customer problem; a disconnected probe is ours. Mixing the two makes the number useless to both.

3. Power health

For battery devices, raw voltage is a poor indicator. A lithium primary cell such as Li-SOCl₂ holds a nearly flat voltage for most of its life and then drops quickly, so a voltage chart looks fine right up until the device dies. Readings also sag under load and shift with temperature.

Where we can, we report a projected days-remaining figure based on energy consumed (counted in firmware from time spent in each power state and radio transmissions) rather than on voltage alone. The tile shows how many devices are projected to fall below a threshold within the next 30 to 90 days, depending on how long a battery swap takes to organise. For mains devices the equivalent is brown-out and supply-fault counts.

4. Data completeness

A device can report on schedule and still lose data: buffered readings that overflow while the gateway is down, messages dropped by the broker, or a parsing error in the backend after a firmware change. Completeness is the number of readings received divided by the number expected over the last 24 hours.

When it drops across the whole fleet at once, the cause is usually on the server side, not in the field.

5. Firmware status

The final tile shows the share of devices on the current release and, during an update, the state of the rollout: how many were offered the update, how many applied it, how many rolled back. A rising rollback count is the signal to pause a staged rollout before it reaches the rest of the fleet.

Defining the numbers so they stay honest

Each tile is only as useful as its definition, and definitions drift. We write them down in the same document as the device’s data contract, alongside the message schema, so the firmware and software teams agree on what “late” or “low battery” means.

Use absolute counts with context. “18 late of 430” is more actionable than “95.8%”.
Compare against a baseline. A small arrow against the same time yesterday or last week shows direction without a chart.
Exclude devices deliberately. Units in storage, awaiting installation or decommissioned should have an explicit state, not quietly drag every metric down.
Make every number clickable. The count should open the filtered list of exactly those devices, sorted by how long they have been in that state.
Compute on the server. Tiles should be calculated in the backend, not in the browser, so the mobile app, alert emails and the web dashboard all report the same figure.

What goes below the fold

A fleet map is useful for installers and for spotting regional problems, such as a gateway outage affecting one site, but it is a poor overview for a fleet of hundreds. We put it one level down, coloured by the same states as the tiles.

Per-device time series, logs and configuration live on the device page. Longer trends, such as fault rates by hardware revision, belong in a weekly reporting view.

View	Who uses it	How often
Five-number overview	Client, operations, support	Daily
Fleet map and filtered lists	Support, installers	When a tile moves
Device detail and logs	Engineers, support	Per incident
Trend reports	Product and engineering leads	Weekly or monthly

Designing firmware for the dashboard

Several of these numbers cannot be calculated unless the device sends the right data. That is why we define the dashboard during architecture, not after the firmware is written. It is one of the benefits of having the firmware, hardware and cloud work done by one team.

At minimum we include a small health payload alongside normal readings: firmware version, reset reason and reset count, an energy or battery estimate, a sequence number so the backend can detect gaps, and radio quality (RSSI and SNR for LoRa, or RSSI for BLE and Wi-Fi). On LoRaWAN, where payloads are small and airtime is limited, this health data can be sent less often than the measurements, for example once a day.

What we would do before building a fleet dashboard

If you are about to specify a dashboard for a connected product, this is the short checklist we work through first.

Write down the five questions your client or operations team asks each morning, and the action each answer triggers.
Define each number precisely, including thresholds, expected intervals and which devices are excluded.
Check that the firmware sends everything those definitions need, including sequence numbers and reset reasons.
Calculate the numbers in the backend and reuse them in the app, alerts and reports.
Make each tile open the exact list of devices behind it.
Review the definitions after the first month in the field, when you know which alerts people actually act on.