IoT device monitoring: why is connecting not enough?

A sensor was installed, connectivity was validated, and the first data reached the platform. The project seems complete. But what happens when that device stops transmitting a few days later? Or when it keeps sending information, but the measurements no longer match reality?

These situations reveal a recurring challenge of the Internet of Things (IoT): putting a device into operation does not guarantee it will keep working as expected.

In a proof of concept, tracking a few devices by hand may seem sufficient. In an operation with assets spread across factories, stores, logistics centers, rural areas, or telecommunications infrastructure, that approach becomes hard to sustain.

The problem is not limited to loss of connectivity. Batteries can run out, sensors can drift, gateways can fail, and applications can stop receiving or processing information. In some cases, the device stays connected to the network but no longer delivers the data operations needs.

It is in this context that IoT device monitoring becomes part of the solution’s operational architecture. Its role is to identify deviations, provide evidence for diagnosis, and allow teams to act before a technical failure produces consequences for the business.

Connecting is not the same as monitoring

Connectivity allows a device to communicate with other components of the environment, such as gateways, processing platforms, and applications. It is necessary for many IoT solutions, but it only confirms that some communication path is available at that moment.

Monitoring adds continuous tracking. Instead of only checking whether communication exists, it seeks to identify whether the device is operating according to the conditions expected for its application.

Consider a simplified temperature monitoring architecture. The sensor takes the measurement, a communication module transmits the data, a gateway forwards it, a central platform processes the information, and an application presents it to the responsible teams. Communication may work in part of this chain while another component fails.

The sensor may transmit an incorrect reading. The gateway may receive the message but not forward it. The platform may process the data, but the dashboard operations uses may stop being updated.

For this reason, checking connectivity answers a limited question: can the device communicate? Monitoring must also answer whether it is sending information on the expected interval, whether the data are consistent, whether there are signs of degradation, and whether the systems that depend on this information keep working.

An active connection does not prove that the solution is fulfilling its function.

Failures do not always interrupt communication

The problems of an IoT solution can manifest in different ways. Some prevent data transmission. Others silently compromise the quality of the information. How each failure appears depends on the device, the protocol, the architecture, the environment, and the installation conditions.

The device stops sending data

Imagine a company that uses sensors to monitor the temperature of equipment distributed across different units. Each sensor must send a measurement periodically to a central platform.

If a device stops transmitting, the last recorded temperature may keep appearing on the dashboard. Without a clear indication of when the data was updated, the team may interpret an old measurement as if it still represented the equipment’s current condition.

The absence of data can have different causes, such as loss of connectivity, power failure, firmware hang, gateway unavailability, or interruption of the service responsible for receiving messages.

A monitoring strategy needs to track sending frequency and measurement freshness. When the device remains without communication beyond the interval expected for its application, the system must flag the condition for investigation.

That interval cannot be the same for all equipment. A sensor that transmits continuously requires different criteria than a meter that sends information once an hour or a device that stays in low-power mode between transmissions. Monitoring must consider the expected behavior, avoiding delays in identifying failures and excessive alerts during normal periods of silence.

The battery runs out without warning

Many IoT devices are installed in hard-to-reach places or depend on batteries to operate for long periods. This characteristic reduces the need for local electrical infrastructure but creates an additional demand for tracking.

Real autonomy depends on battery capacity, transmission frequency, signal quality, environmental conditions, and equipment behavior. Repeated connection attempts or more frequent transmissions can raise energy consumption. In other cases, degradation occurs gradually until communication is interrupted.

If operations does not track the energy state, the team may discover the problem only when the device stops transmitting. For remote assets, replacement may require travel, access authorization, mobilization of professionals, and prolonged unavailability of information.

When the equipment provides this telemetry, monitoring can track battery level, consumption trend, and other energy health indicators. Not every device offers these data, and not every indicator allows precise estimation of remaining autonomy. Therefore, the strategy must combine the available resources with the operating history and the maintenance plan.

The device stays connected but sends incorrect data

This is one of the most delicate scenarios. Communication remains active, but the quality of the information is compromised.

A sensor may show calibration drift, hold a frozen reading, or produce values incompatible with the process conditions. Errors in unit conversion, interpretation, or handling may also occur along the processing chain.

A scientific review published by Sharma et al. analyzes sensor errors and fault detection techniques in smart environments. The authors show that sensor failures can compromise the reliability of the systems that depend on these measurements [3].

The challenge is to distinguish an instrumentation failure from a real change in the monitored environment. If a sensor in a refrigeration system records exactly the same temperature for several hours, despite operational changes, the continuity of communication does not guarantee that the measurement is still useful.

Monitoring can help through plausibility checks, identification of values outside defined limits, detection of frozen readings, and comparison with history or with related sensors. These criteria must respect the physical context. An abrupt variation may represent a defect, but it may also indicate a real event that requires immediate attention.

The goal is not to automatically discard unusual values, but to identify situations that need to be investigated.

The field team receives insufficient information

When there is little visibility into the devices, the investigation starts with incomplete information. A technician may be sent to check a sensor that stopped transmitting and find the equipment working normally. The real cause may lie in the gateway, network coverage, power at the concentration point, or the central platform.

The reverse can also happen. The team identifies the failing device but lacks enough data to bring the right part or carry out the necessary procedure. The result may include additional trips, unproductive hours, and a longer time to restore service.

Monitoring does not eliminate the need for on-site visits. Physical failures, component replacements, and maintenance activities will continue to require intervention in many scenarios. Its benefit lies in improving the diagnosis before travel, prioritizing incidents, and providing more useful information to the field team.

Communication history, the last data received, battery indicators, gateway events, and recent configuration changes can be decisive for this diagnosis.

What needs to be observed throughout operation

There is no single list of indicators suited to every project. The choice depends on the device’s purpose, the architecture, the criticality of the information, and the capabilities offered by the equipment.

In general, a monitoring strategy can consider device availability, time since last communication, expected message frequency, signal quality, battery state, transmission errors, configuration changes, and consistency of the collected data.

It is also necessary to observe the components that support the solution. Gateways, message queues, ingestion services, processing platforms, databases, and applications are part of the chain that turns a physical measurement into useful information. The unavailability of any of these elements can compromise the service even when the sensor keeps working.

The National Institute of Standards and Technology (NIST) treats the individual identification of assets as an important capability for managing devices and their components. In its IoT cybersecurity guidance, the institute also includes awareness of the device’s security state, which may involve event logging, sending signals to external monitoring systems, and alerts [1][2]. Although this guidance focuses on security, it reinforces two foundations useful for operations: knowing exactly which asset is being tracked and receiving evidence about its condition.

The context of each application remains decisive. A delay of minutes may be acceptable in a periodic environmental measurement and critical in another process. Likewise, a value outside the historical range may indicate a failure or a legitimate operating condition. Monitoring criteria must reflect the function the device performs, not just the capabilities of the platform used.

The impact goes beyond the team responsible for the devices

The consequences of insufficient monitoring can reach different areas of the organization.

IT and infrastructure teams need to determine whether the failure is in the equipment, the network, the gateways, or the central services. Without related information, diagnosis can take longer and involve several teams until the cause is identified.

Operations and maintenance depend on reliable data to track equipment, plan interventions, and recognize abnormal conditions. A missing or incorrect measurement can compromise the interpretation of an operational situation.

Telecommunications and field teams need to distinguish coverage, communication, configuration, and physical failure problems. The more distributed the devices, the greater the need for a consolidated view of the assets and their operating conditions.

Managers feel the effects when the unavailability of information delays decisions, compromises processes, generates additional costs, or reduces the reliability of a service delivered to the customer.

In a logistics operation, for example, a tracker that stops updating an asset’s location creates uncertainty. The responsible area may not know whether there was a loss of communication, a power failure, or a problem in the system that receives the data. In an industrial operation, the absence of information from a critical sensor can reduce the ability to track the condition of a piece of equipment.

Criticality is not determined only by the value of the device. It depends on what becomes impossible when the information is unavailable or unreliable.

Reliability must continue after installation

Connecting an IoT device is the beginning of an operational journey. Over time, equipment can stop transmitting, develop power problems, generate incorrect measurements, or depend on infrastructure components that are also subject to failure.

Monitoring helps turn these occurrences into observable conditions, with information that makes it possible to identify deviations, investigate causes, and direct actions. Its value depends on the quality of the available data, the suitability of the indicators, and the integration with service and maintenance processes.

For managers in IT, telecommunications, infrastructure, and operations, the central question must not be only how many devices are connected. It is necessary to know how many work as expected, whether the data received are reliable, and how the team will be informed when something falls outside the pattern.

A reliable IoT solution must keep working, producing useful data, and allowing operations to recognize and handle problems throughout its entire lifecycle.

About Target Solutions

Target Solutions has spent more than 15 years helping organizations evolve their infrastructure, monitoring, observability, automation, and operational intelligence operations. Across that journey, it has participated in projects in complex environments such as telecom, technology, government, energy, and large enterprises, helping increase operational efficiency and service reliability.

That experience also includes Internet of Things (IoT) projects, where connectivity, technical integration, and operational follow-up matter to turn connected devices into useful solutions for organizations.

About the author

Paulo Florêncio de Menezes is cofounder of Target Solutions and has spent more than 15 years on projects involving infrastructure, monitoring, observability, automation, and IT and telecom operations.

He holds a degree in data processing from the Federal University of Amazonas (UFAM), an MBA in business management from Fundação Dom Cabral (FDC), and a professional master’s in economics from Fundação Getulio Vargas (FGV).

In his master’s research, he developed the IBEOP-IA (Brazilian Index of Occupational Exposure Potential to Artificial Intelligence), studying the potential exposure of Brazilian occupations to AI capabilities by combining occupational data, artificial intelligence patents, and natural language processing techniques.

References

[1] FAGAN, Michael; MEGAS, Katerina; SCARFONE, Karen; SMITH, Matthew. IoT Device Cybersecurity Capability Core Baseline. NISTIR 8259A. National Institute of Standards and Technology, 2020.

[2] NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. Frequently Asked Questions: NIST Cybersecurity for IoT Program.

[3] SHARMA, Sheetal; GUPTA, Kamali; GUPTA, Deepali; RANI, Shalli; DHIMAN, Gaurav. An Insight Survey on Sensor Errors and Fault Detection Techniques in Smart Spaces. Computer Modeling in Engineering & Sciences, v. 138, n. 3, p. 2029-2059, 2024.