IoT monitoring is the continuous collection and analysis of data from connected devices, their networks and the cloud services behind them, so you can see whether each device is online, healthy and secure. It turns telemetry such as connectivity, battery, temperature and traffic patterns into alerts and dashboards before a fault stops operations.
Key takeaways
- Monitor four layers: the device itself, the network that connects it, the cloud platform that receives its data, and the security behaviour of the whole fleet.
- Start with a small set of health signals per device type (last seen, battery, firmware version, error rate) and add more only when someone will act on them.
- Alert on fleet-level patterns, such as "connected devices dropped below a threshold", rather than paging on every single offline sensor.
- Cloud platforms include monitoring tools: AWS IoT Device Defender audits configuration and detects abnormal device behaviour, and Azure Monitor tracks connected devices on Azure IoT Hub.
- Security monitoring is becoming a legal duty for manufacturers in the EU: Cyber Resilience Act reporting obligations apply from 11 September 2026.
What does IoT monitoring cover?
It covers everything between the sensor and the business decision. A useful way to plan it is by layer, because each layer fails in a different way and needs different data.
| Layer | What you watch | Typical failure it catches |
|---|---|---|
| Device health | Last heartbeat, uptime, battery or power, CPU and memory, temperature, firmware version, error counters | Dead batteries, overheating, crash loops, devices stuck on old firmware |
| Connectivity | Connect and disconnect events, signal strength, latency, message delivery rate, retries | Gateway outages, poor cellular coverage, a misconfigured access point |
| Data and platform | Message throughput, ingestion errors, queue depth, rule or function failures, storage growth | Silent data loss, throttling, a broken pipeline after a deployment |
| Security | Authentication failures, certificate expiry, unexpected destinations, traffic spikes, open ports | Compromised devices, cloned credentials, botnet behaviour |
| Business process | The physical value being measured: pressure, vibration, fill level, temperature in a cold chain | Equipment wear, spoiled goods, process drift |
The last row is where most of the value sits. Device and network monitoring keep the data flowing. Process monitoring uses that data, for example to plan predictive maintenance before a pump fails.
Why does monitoring connected devices matter?
Because IoT fleets fail quietly. A sensor that stops reporting does not raise an error on its own. Without monitoring you find out when a report is empty, a freezer has warmed up or a customer calls.
Three reasons come up in almost every project:
- Uptime of physical operations. Devices are often in places that are expensive to visit. Knowing which unit is down, and why, cuts truck rolls and downtime.
- Data quality. Analytics and machine learning models are only as good as the input. Gaps, drift and stuck values need to be caught at the source.
- Security. Devices run for years, often with limited patching. Behaviour monitoring is the practical way to spot a device that has been taken over.
How does it work in practice?
Devices publish telemetry to a gateway or directly to a cloud IoT service. The platform stores metrics and events, evaluates rules and sends alerts to the people or systems that act on them.
- Instrument the device. Send a heartbeat and a small health payload at a fixed interval, separate from the business data.
- Track state centrally. Keep a record of each device's last reported and desired state. On AWS this is the Device Shadow service; Azure IoT Hub uses device twins.
- Collect platform metrics. Azure Monitor for IoT Hub provides a "Connected devices" metric that can alert when the count drops below a threshold, plus connection events for each device.
- Watch for abnormal behaviour. AWS IoT Device Defender runs audit checks against security best practice and evaluates device metrics against rules you define (Rules Detect) or machine learning models (ML Detect).
- Route alerts and act. Send alerts to an on-call tool or ticket queue, and where possible trigger an automated action such as revoking a certificate or restarting a service.
What metrics should you start with?
Start with the signals that tell you a device is alive and trustworthy, then add process metrics per use case. A practical first set:
- Time since last message, per device and per device type
- Percentage of the fleet connected, compared with the same hour last week
- Battery level or supply voltage trend
- Firmware version distribution across the fleet
- Message error rate and ingestion failures
- Days until device certificates expire
- Authentication failures and connections to unexpected endpoints
Set thresholds per device class. A battery-powered sensor that reports every hour needs a different "offline" rule from a mains-powered gateway that reports every 30 seconds.
Common mistakes to avoid
- Alerting on every device. In a fleet of thousands, single-device alerts cause alert fatigue. Alert on patterns and send single-device issues to a work queue.
- Mixing health and business data. If the health heartbeat travels in the same payload as sensor readings, a parsing bug can hide both.
- No owner for alerts. Decide who responds to each alert type, at what hours, before go-live.
- Ignoring certificates and firmware. Expired certificates and outdated firmware are common causes of mass disconnects and security gaps.
- Monitoring only the cloud side. Edge gateways often run local logic. They need their own health checks and log collection.
Security and compliance requirements
Security monitoring is moving from good practice to obligation in Europe. Under the EU Cyber Resilience Act, which entered into force on 10 December 2024, manufacturers of products with digital elements must report actively exploited vulnerabilities and severe incidents from 11 September 2026, and the main obligations apply from 11 December 2027.
The CRA places duties on manufacturers. If you operate devices rather than build them, the practical consequence is that you need to know what is in your fleet, which firmware versions run where and how quickly you can roll out a fix. Organisations covered by NIS2 also need monitoring and incident handling for the systems their essential services depend on, which often include OT and IoT devices. For consumer IoT, the ETSI EN 303 645 baseline lists security provisions such as no universal default passwords and keeping software updated.
How Opsio helps
Opsio designs and builds IoT solutions on AWS and Azure and runs the cloud side as a managed service. That includes device onboarding, telemetry pipelines, dashboards and alert routing, with 24/7 monitoring through our managed IT services. If you are starting a new product or fleet, our IoT development team can set up monitoring from day one rather than adding it after the first outage.
Related reading: remote IoT monitoring use cases and IoT device management.
Frequently asked questions
What is the difference between IoT monitoring and IoT management?
Monitoring observes devices and alerts on problems. Management acts on devices: provisioning, configuration, firmware updates and decommissioning. Most platforms offer both, and monitoring data tells you where management action is needed.
What tools are used to monitor IoT devices?
Cloud IoT platforms provide the base: AWS IoT Core with Device Defender and CloudWatch, or Azure IoT Hub with Azure Monitor. Teams often add a time-series database and dashboards such as Grafana, and an on-call tool for alert routing.
How often should IoT devices send health data?
It depends on power and cost. Mains-powered gateways can send a heartbeat every few seconds or minutes. Battery-powered sensors often report every 15 to 60 minutes, so "offline" rules must allow for several missed intervals.
Can IoT monitoring detect cyber attacks?
It can detect many of them through behaviour: unusual traffic volumes, connections to unknown destinations, repeated authentication failures or devices reporting at odd times. It does not replace patching, strong device identity and network segmentation.
Is the Cyber Resilience Act relevant if we only use IoT devices?
The main obligations fall on manufacturers, importers and distributors. Users still benefit from tracking firmware versions and vulnerability notices, because manufacturers will publish fixes that you need to roll out.
Written By
Head of Innovation
Jacob leads innovation at Opsio, specialising in digital transformation, AI, IoT, and cloud-driven solutions that turn complex technology into measurable business value. With nearly 15 years of experience, he works closely with customers to design scalable AI and IoT solutions, streamline delivery processes, and create technology strategies that drive sustainable growth and long-term business impact.
Editorial standards: This article was written by the cloud practitioner named in the byline above. We revise it when the technology or regulation it covers changes; the dates on this page show the latest update. Opsio maintains editorial independence.