How to Fix MQTT Messages Arriving Out of Order or Dropped

Back to Blog

First Checks

Separate the two symptoms first, because they have different causes. Out of order means every message arrives but the sequence is scrambled. Dropped means messages are missing entirely. If you are not sure which you have, add a monotonic sequence number to the payload at the publisher - gaps mean drops, reordering means an ordering problem. This one addition turns a vague complaint into a diagnosable fact.

Then confirm the QoS actually in effect on both the publish and the subscribe, because delivery is capped by the lower of the two. A publisher at QoS 1 delivering to a subscriber that subscribed at QoS 0 gets QoS 0 delivery, with its loss risk. Ground the levels in MQTT QoS levels 0, 1, and 2 before assigning blame.

Fix Dropped Messages From QoS 0 on a Lossy Link

The most common cause of dropped messages is QoS 0 over a link that loses packets. QoS 0 has no acknowledgement and no retry, so a message lost in transit is simply gone with no error anywhere. On a clean LAN this almost never shows; on a cellular or satellite link it shows regularly. The test is to raise the topic to QoS 1 and see if the drops stop.

If the values are the kind that must not be lost - totalizers, states, alarms - QoS 1 is the correct fix, not a workaround. If they are high-rate trend data where the next sample supersedes a loss, QoS 0 drops may be acceptable and you were mis-reading normal behavior as a fault. Decide with the method in choosing an MQTT QoS for telemetry.

Fix Drops From a Session That Discarded Queued Messages

Messages published while a subscriber was disconnected are only held if the subscriber has a persistent session and used QoS 1 or 2. A clean session tells the broker to discard everything the moment the client disconnects, so a subscriber that reconnects with a clean session finds its queue empty and never learns what it missed. That looks exactly like dropped messages.

The fix is a persistent session with a session expiry long enough to cover the expected outage, plus QoS 1 or higher on the topics that matter. Then queued messages survive the disconnect and flush on reconnect. The tradeoff and the flags are in MQTT clean session vs persistent session.

Fix Out-of-Order Delivery From Client Concurrency

MQTT preserves per-topic ordering for a single-threaded client at a given QoS, but that guarantee dissolves when the client processes messages concurrently or publishes from multiple threads without coordination. If your consumer hands each message to a worker pool, the workers finish in an order the broker never controlled, and you see reordering that is entirely on the consumer side.

Reordering also appears after a reconnect when QoS 1 or 2 redelivers unacknowledged messages, which can interleave with new ones. If strict order matters, keep the processing single-threaded per topic, or carry a sequence number in the payload and reorder on the consumer. Do not expect the broker to fix an ordering requirement that your own concurrency broke.

Fix Drops From a Saturated Inflight Window

At QoS 1 and 2 a client may have only a limited number of unacknowledged messages in flight at once. On a slow link where acknowledgements are delayed, that window fills, and depending on the client, further publishes either block or are dropped. A publisher that drops when the window is full looks like message loss but is really backpressure you did not tune for.

The fix is to size the inflight window and the client's send queue for the link's latency, or slow the publish rate to what the link can acknowledge. This is the same tuning as any slow-link case - see MQTT receive maximum and flow control for the mechanism that governs how many messages the receiver will accept at once.

When to Escalate

If drops or reordering persist after QoS, session, concurrency, and inflight are all correct, and a payload sequence number confirms the loss is real between a single publisher and a single subscriber, the broker or a bridge between brokers becomes a suspect. A bridged topology can reorder or drop across the bridge independently of your client settings.

Escalate to the broker owner with the sequence-number evidence, the QoS and session settings of both ends, and whether a bridge sits in the path. Precise evidence that the client side is clean is what turns a broker investigation from guesswork into a targeted one.

Frequently Asked Questions