Most IoT dashboards report the wrong things. They show device counts, message totals, and uptime percentages — numbers that look reassuring and predict almost nothing. A fleet can report 99.9 percent platform uptime while a third of its devices are hours behind and nobody notices.
Useful KPIs share one property: each answers a question someone would act on. If a metric moves and nothing changes as a result, it is decoration.
This guide covers the metrics that actually predict the health of a connected product, grouped by the layer they measure, along with how to define each one so the number means something.
What Makes an IoT KPI Worth Tracking
Before the list, four rules that separate metrics that help from metrics that fill a screen.
- Measure per device, then aggregate. Fleet averages hide the tail. A mean connectivity of 97 percent may be a healthy fleet or 3 percent of devices permanently offline — two completely different problems.
- Use percentiles, not means. The 95th and 99th percentiles describe what users actually experience. Averages describe a device that may not exist.
- Prefer leading indicators. Queue depth rises before latency does. Battery trajectory declines before a device dies. Lagging metrics tell you what already went wrong.
- Attach an action. Every KPI should have a threshold and a named response. Without both, it is a number nobody owns.
If a metric changes and nobody does anything differently, stop collecting it and free the space on the dashboard.
Device and Connectivity KPIs
These describe whether the fleet is physically working. They are the foundation, and weakness here invalidates everything above.
| KPI | Definition | Why it matters |
|---|---|---|
| Connectivity rate | Share of devices reporting within their expected interval | The single clearest indicator of fleet health |
| Data completeness | Messages received divided by messages expected, per device | Catches silent loss that error rates never show |
| Delivery latency | Ingest time minus event time, at the 95th percentile | Reveals devices reporting stale data |
| Battery trajectory | Projected days remaining from the discharge trend | Turns replacement into planned work |
| Reset frequency | Unexpected restarts per device per week, with cause | Leading indicator of power or firmware problems |
| Signal quality | RSSI or equivalent, trended per device | Identifies marginal installations before they fail |
Data completeness is the most underused metric in this group. It requires knowing what each device should have sent, which many platforms never model — and without it, a device that silently halves its reporting rate looks perfectly healthy.
Data Quality KPIs
Data can arrive reliably and still be wrong. These metrics measure whether the readings can be trusted.
Platform and Performance KPIs
- Ingestion throughput and headroom — current rate against tested capacity. Headroom is the number that matters; utilisation alone gives no warning.
- Queue depth and consumer lag — the earliest reliable warning of saturation, rising well before latency does.
- End-to-end latency, 95th and 99th percentile — from event time on the device to action taken, not per component.
- Query response time — trended over months. Gradual decline signals missing retention and rollup policy, and it worsens regardless of fleet size.
- Error rate by type — separated into device, transport, and platform causes so responsibility is unambiguous.
- Cost per device per year — connectivity, ingestion, storage, and compute combined. This is what decides whether scaling is viable.
These sit at the point where IoT system performance problems first become visible, usually months before anyone complains.
Fleet Operations KPIs
These measure whether the fleet can be managed and changed — which determines how quickly any problem can be fixed.
| KPI | What it reveals |
|---|---|
| Firmware update success rate | Whether the fleet is correctable at all |
| Firmware version distribution | How much variation the platform must support |
| Time to onboard a new site | Whether deployment is scaling or merely repeating |
| Support tickets per 100 devices | The true operational load per unit deployed |
| Mean time to diagnose | Whether devices report enough to be understood remotely |
| Field replacement rate | Real reliability, and the cost the business case must absorb |
Update success rate deserves particular attention. A fleet that cannot be updated reliably has a fixed permanent behaviour, and every future improvement becomes a site visit.
Business Impact KPIs
Technical metrics justify engineering decisions. Business metrics justify the programme, and they must be expressed in units the organisation already uses.
| Technical KPI | Business outcome it supports |
|---|---|
| Firmware update success | Reduced field service cost |
| Connectivity rate | Higher customer satisfaction and trust |
| Data accuracy | Better operational decisions |
| Platform latency | Faster response to incidents |
| Alert precision | Less wasted maintenance effort |
| Fleet health | Increased product reliability and lower warranty cost |
Alert precision — the share of alerts that turn out to be real and actionable — is the metric most closely tied to whether a system keeps being used. Two false alarms do more damage to adoption than a dozen missed events, because operators stop trusting the system entirely.
Making KPIs Operationally Useful
Frequently Asked Questions
Conclusion
The metrics that predict IoT success are unglamorous: what fraction of expected data arrived, how old it was when it was used, whether the fleet can be updated, and what each device costs to run for a year.
Measure per device before aggregating, use percentiles, favour leading indicators, and attach an owner and an action to every number. A short dashboard where every metric triggers a response is worth far more than a long one where none of them do.