IoT Hub: Devices Not Reporting Online Despite Communication — Investigating Discrepancies

Question

IoT Hub: Devices Not Reporting Online Despite Communication — Investigating Discrepancies

LWB 20

Problem description

I am experiencing an issue where my IoT Hub devices are not reporting their online status correctly. The devices appear to connect and send twin updates, but my platform continues to show them as offline or disconnected.

The issue is caused by Azure not sending the deviceConnected event, after deviceDisconnected event even though a device is connected and fully functional.

Environment

Azure IoT Hub in West Europe. The hub is routing device connection-state events, twin-change events, and lifecycle events.

What I've already tried

I compared device-side logs with the platform’s status records, providing timestamps and sequence information to illustrate the connect, disconnect, and twin-change events. I reviewed diagnostic information indicating potential maintenance-related temporary disconnects in the past 24 hours and observed that the hub successfully routed relevant events during that period. I also referenced standard IoT Hub guidance on connection-state tracking and intermittent disconnects, but the case does not specify whether those conditions were confirmed.

Current status

I am seeking assistance to understand why Iot Hub did not send a deviceConnected event (after sending disconnected event) for a device connected. Thus causing inconsistent status in the backend.

Example TimeLine:

Device is connected. deviceDisconnected event is sent and captured by our backend. While still connected, no other event is sent to us, meaning that the device remains offline in the backend.

ARUL OLY 0 Reputation points

2026-09-14T10:43:51.92+00:00
Hi LWB,

What you are experiencing is a known architectural behavior when relying strictly on Azure IoT Hub Device Connected/Disconnected lifecycle events via Event Grid or Routing.

Because IoT Hub protocols (MQTT/AMQP) allow rapid, transient reconnections, it is highly common for a device to briefly drop and reconnect faster than the event pipeline processes the status. Here is an analysis of why this happens and how to fix the discrepancy in your backend.

Why This Happens: Out-of-Order Events & Duplication

Event Grid/Routing is "At-Least-Once" Delivery: Azure guarantees that connection events will be delivered, but it does not guarantee sequential order. A deviceConnected event can arrive at your backend before the preceding deviceDisconnected event due to internal network retries.

The "Heartbeat" Deception: When a device abruptly loses connection (e.g., cell tower switch, minor drop), the IoT Hub relies on the protocol keep-alive timeout (MQTT Ping). If the device reconnects before the hub realizes it was gone, the hub will register a new connection, kill the old half-open connection, and then emit the deviceDisconnected event for the old session after the new session is already live. If your backend processes that disconnect last, the state sticks to "offline".
LWB 20 Reputation points

2026-09-14T11:40:48.8366667+00:00

Hello! "The "Heartbeat" Deception" describes our issue perfectly.

Devices connected, suddenly receive an offline event even though they are connected. But the never get a new online event.

Is there any tweaking or recommendation to try to avoid this? Maybe a heartbeat parameter or reconnection flow/pattern we should implement in the device?

We have 150k devices connected and we see this is becoming a problem for a couple of them.
LWB 20 Reputation points

2026-09-14T11:46:17.8433333+00:00

Just to add more context:

Our devices use the C SDK v1.13.0 (LTS_08_2024)

Using MQTT over websockets

Also, is there any "session" or any identifier that could help the device or even the backend to know when such issue happened? Maybe use this to trigger a full disconnect/reconnect flow
Thanmayi Godithi 11,825 Reputation points Microsoft External Staff Moderator

2026-09-14T16:21:28.8766667+00:00

Hi LWB ,

Could you please share the details requested over Private message?
LWB 20 Reputation points

2026-09-15T08:33:13.4066667+00:00

Shared
Thanmayi Godithi 11,825 Reputation points Microsoft External Staff Moderator

2026-09-16T10:13:48.77+00:00
@LWB , Thank you for the additional details.

Based on the behavior described, this is consistent with a documented limitation of IoT Hub device connection-state events. IoT Hub does not publish every individual connect/disconnect transition. Instead, connection-state events are emitted based on the current connection state observed in a periodic snapshot, which means short-lived disconnect/reconnect cycles may not always result in a matching DeviceConnected event.

Additionally, Event Grid does not guarantee event ordering, so connection-state events should not be treated as a strictly ordered online/offline stream.

For solutions where accurate device presence is critical, Microsoft recommends combining lifecycle events with a device heartbeat or last-seen timestamp rather than relying solely on DeviceConnected/DeviceDisconnected events.

Regarding your specific questions:

• There is no documented IoT Hub setting or MQTT keep-alive configuration that guarantees generation of a new DeviceConnected event after a transient reconnect. • Devices using the Azure IoT C SDK should continue sending periodic telemetry or heartbeat messages so backend services can validate presence independently of lifecycle events. • Device connection-state events include a sequenceNumber field that may be useful when processing and ordering events on the backend.

Relevant documentation:

Monitor device connection status: https://learn.microsoft.com/azure/iot-hub/monitor-device-connection-state

Device connection-state event limitations: https://learn.microsoft.com/azure/iot-hub/iot-hub-devguide-messages-d2c#limitations-for-device-connection-state-events

IoT Hub connectivity monitoring guidance: https://learn.microsoft.com/azure/iot-hub/iot-hub-troubleshoot-connectivity

If you continue to observe long-running connected devices that never generate a corresponding DeviceConnected event after a disconnect event, please share:

IoT Hub name and region

Device ID

UTC timestamps

Correlation of disconnected event, subsequent twin updates, and any telemetry activity

This would help determine whether the behavior is explained by the documented connection-state limitations or whether a service-side investigation is required.
LWB 20 Reputation points

2026-09-16T11:23:49.6933333+00:00

If you continue to observe long-running connected devices that never generate a corresponding DeviceConnected event after a disconnect event, please share:

Usually, when we perform a reboot they reconnect and we receive correct status. But I will keep an eye for this and report to you if we see this happening.

Alright. We will look into other ways of fixing this, including heartbeat implementation.

Thanks!

Your answer

ARUL OLY 0 Reputation points

2026-09-14T10:43:51.92+00:00

Hi LWB,

What you are experiencing is a known architectural behavior when relying strictly on Azure IoT Hub Device Connected/Disconnected lifecycle events via Event Grid or Routing.

Because IoT Hub protocols (MQTT/AMQP) allow rapid, transient reconnections, it is highly common for a device to briefly drop and reconnect faster than the event pipeline processes the status. Here is an analysis of why this happens and how to fix the discrepancy in your backend.

Why This Happens: Out-of-Order Events & Duplication

Event Grid/Routing is "At-Least-Once" Delivery: Azure guarantees that connection events will be delivered, but it does not guarantee sequential order. A deviceConnected event can arrive at your backend before the preceding deviceDisconnected event due to internal network retries.

The "Heartbeat" Deception: When a device abruptly loses connection (e.g., cell tower switch, minor drop), the IoT Hub relies on the protocol keep-alive timeout (MQTT Ping). If the device reconnects before the hub realizes it was gone, the hub will register a new connection, kill the old half-open connection, and then emit the deviceDisconnected event for the old session after the new session is already live. If your backend processes that disconnect last, the state sticks to "offline".
LWB 20 Reputation points

2026-09-14T11:40:48.8366667+00:00

Hello! "The "Heartbeat" Deception" describes our issue perfectly.

Devices connected, suddenly receive an offline event even though they are connected. But the never get a new online event.

Is there any tweaking or recommendation to try to avoid this? Maybe a heartbeat parameter or reconnection flow/pattern we should implement in the device?

We have 150k devices connected and we see this is becoming a problem for a couple of them.
LWB 20 Reputation points

2026-09-14T11:46:17.8433333+00:00

Just to add more context:

Our devices use the C SDK v1.13.0 (LTS_08_2024)

Using MQTT over websockets

Also, is there any "session" or any identifier that could help the device or even the backend to know when such issue happened? Maybe use this to trigger a full disconnect/reconnect flow
Thanmayi Godithi 11,825 Reputation points Microsoft External Staff Moderator

2026-09-14T16:21:28.8766667+00:00

Hi LWB ,

Could you please share the details requested over Private message?
LWB 20 Reputation points

2026-09-15T08:33:13.4066667+00:00

Shared
LWB 20 Reputation points

2026-09-16T11:23:49.6933333+00:00

If you continue to observe long-running connected devices that never generate a corresponding DeviceConnected event after a disconnect event, please share:

Usually, when we perform a reboot they reconnect and we receive correct status. But I will keep an eye for this and report to you if we see this happening.

Alright. We will look into other ways of fixing this, including heartbeat implementation.

Thanks!