IotHub Broker Specs

If you're looking for a full featured MQTT broker hosted in Azure, then take a look at https://free.blessedness.top/en-us/azure/event-grid/mqtt-overview. Azure Event Grid supports both MQTT v3.1.1 and v5.

Hi Alex,

Fantastic piece of info, much appreciated.

The retain message feature from MQTT spec isn't supported. In a full broker, retained messages stay on the broker and get delivered to new subscribers immediately when they connect. IoT Hub handles this differently through its own message routing and processing.

I believe this is key:

Session state management is limited. Full MQTT brokers maintain client sessions across disconnections, but IoT Hub has its own connection state management that's optimized for scale rather than strict MQTT compliance.

Just to clarify above a constructed example:

• ServiceA sends payload to DeviceA (Asks for some dataset say a JSON payload) with following specs:
• QoS=1
• TTL=60sec
• Timeout=30sec
• DeviceA we assume is online:
• keepAlive=300sec
• healthy PINGREQ/PINGRES

Lets assume the request failed (ServiceA<>IotHub)

• DeviceA didn't record any network issues (well on MQTT level this just means state between 300sec was success but anything can happen in between).

Few questions if you don't mind:

• Do you have anywhere potentially failure modes listed to address this?
• Messages are not persisted so no Retires?
  • As If device is offline TTL is in effect I'd guess temp buffer must be present.
• A silly but obvious question does IoTHub support retry and/or TTL for the payload itself?
• Lastly, any suggestions in improving resilience in comms (whole chain)?

If my interpretation of the specs is correct the following would be required at min:

• QoS=1
• TTL>=deviceKeepAlive
• timeout=30sec
  • No really network issues expected between (ServiceA-IotHub)

Hi Iliev Dimitar,

Thank you for the detailed follow-up and great analysis of the IoT Hub MQTT behavior.

You’re absolutely correct that Azure IoT Hub’s MQTT implementation prioritizes scalability and reliability for telemetry workloads, rather than full MQTT broker compliance. Let’s address each of your points and clarify how IoT Hub handles message delivery, retries, and session state management.

Failure Modes & Message Persistence

IoT Hub provides at-least-once delivery for device-to-cloud (D2C) messages and best-effort delivery for cloud-to-device (C2D) messages when using MQTT.

If ServiceA → IoT Hub message fails: There’s no automatic retry at the IoT Hub layer for upstream messages. If your service publishes via the IoT Hub service SDK or REST API, retry logic must be implemented in the application layer. Azure SDKs include exponential backoff policies that you can use.

If DeviceA is offline: IoT Hub temporarily queues cloud-to-device messages based on the Time-to-Live (TTL) value defined in the message property (default: 1 hour, max: 48 hours). Once TTL expires, undelivered messages are dropped automatically. This serves as a “temporary buffer,” but IoT Hub does not retain messages indefinitely or persist them for replay when a device reconnects.

If DeviceA is online but fails to ACK (QoS=1): IoT Hub will retry delivery until it receives PUBACK from the device or TTL expires whichever occurs first. This provides a degree of reliability similar to MQTT QoS 1 semantics.

Session State & Connection Handling

You’re correct IoT Hub doesn’t maintain full MQTT session state (such as inflight messages, subscriptions, or retained topics) across reconnects. Instead, session state is reset on reconnection, and any unacknowledged messages that expired during disconnection are lost.

This tradeoff allows IoT Hub to scale to millions of devices, but it does mean applications should handle reconnection and retransmission logic explicitly if consistent session behavior is required.

Retry and TTL Behavior

TTL: Configurable per message via the expiryTimeUtc property (up to 48 hours).

Retry:

• IoT Hub retries cloud-to-device delivery (within TTL).
• For device-to-cloud, retries must be implemented by the sender.

No built-in retry for expired or dropped messages once TTL expires, messages are discarded.

Recommendations for Resilient Communication

To improve resilience across ServiceA ↔ IoT Hub ↔ DeviceA:

Set QoS = 1 for cloud-to-device commands that require acknowledgement.

1. Align TTL with device connectivity patterns e.g., TTL ≥ deviceKeepAlive (your assumption here is correct).

Implement application-level retries for ServiceA → IoT Hub sends (especially if you’re calling IoT Hub APIs directly).

Use Azure Monitor or Event Grid to track message delivery failures or expired messages.

Consider using Device Twins or Direct Methods for command/response patterns requiring guaranteed synchronization instead of relying solely on MQTT message flows.

Log connectivity metrics (PINGREQ/PINGRESP, reconnects, unacknowledged PUBACKs) to detect transient failures that MQTT-level pings might not capture.

Please refer this,

• IoT Hub MQTT Support
• IoT Hub Message Lifecycle & TTL
• IoT Hub Reliability and Retry Guidelines

You’re interpreting the specs correctly IoT Hub provides temporary buffering and at-least-once delivery guarantees within the message TTL, but it does not retain session state or support retained messages. For resilience, align TTL with keep-alive intervals, use QoS=1, and implement application-level retries for both ServiceA and DeviceA..

Thank you!