MQTT quality of service level 1 promises that a message will be delivered at least once. The words at least are doing a lot of work: they mean the same message can legitimately arrive twice. This is not a bug or a broken broker - it is the direct consequence of how QoS 1 guarantees delivery over an unreliable network. This guide explains exactly when and why a duplicate happens, what the DUP flag signals, why consumers of QoS 1 telemetry have to be built to tolerate repeats, when a duplicate actually matters, and why many teams still prefer QoS 1 over the heavier QoS 2 handshake.
QoS 1 Duplicate Delivery in one line: MQTT QoS 1 guarantees at-least-once delivery, which means duplicates are possible by design. When a publisher sends a message and the acknowledgment (PUBACK) is lost or delayed, the publisher cannot tell whether the message arrived, so it resends it with the DUP flag set. The message may therefore be delivered twice. Because of this, QoS 1 consumers must be built to handle duplicates safely, typically by making their processing idempotent.
QoS 1 works by requiring an acknowledgment for every message. The sender publishes a message and holds onto it, waiting for the receiver to send back a PUBACK confirming receipt. Only when the PUBACK arrives does the sender consider the message delivered and discard its stored copy. This store-and-acknowledge loop is what turns an unreliable network into an at-least-once guarantee: as long as the sender keeps a copy and keeps waiting, the message will not be lost.
The duplicate arises from a specific failure: the message gets through, but the acknowledgment does not. Imagine a publisher sends a telemetry reading, the broker receives it and processes it correctly, and the broker sends back a PUBACK - but that PUBACK is lost on the way back, or the network drops just as it is sent. From the publisher's point of view, nothing came back. It has no way to distinguish a message that never arrived from a message that arrived but whose acknowledgment was lost. Faced with that ambiguity, the only safe choice consistent with at-least-once is to resend, so the publisher transmits the message again.
When it resends, the publisher sets the DUP flag on the message. DUP is short for duplicate, and it is the protocol's way of saying this is a retransmission of a message I already tried to send, not a fresh one. Importantly, the DUP flag is a hint about the send attempt, not a reliable dedup key on its own - it tells a receiver the sender is retrying, but the receiver still ends up with the message content twice if it processed the first copy. The result is that the same reading is delivered a second time, which is exactly what at-least-once permits.
Because QoS 1 can deliver the same message twice, any consumer of QoS 1 data has to be built so that processing a message twice does no harm. The technical word for this is idempotent: an operation is idempotent if doing it repeatedly has the same effect as doing it once. If a handler simply stores the latest value of a tag, it is naturally idempotent - writing the same reading twice leaves the same value, and the duplicate is harmless. Problems appear when a handler does something that accumulates, like incrementing a total or appending a row, because then the second copy changes the result.
The practical way to make a handler idempotent is usually to give messages a stable identity and to make the processing depend on that identity rather than just on the fact that a message arrived. A consumer can carry its own notion of which message it has already applied - for instance keying on a timestamp, a source sequence number, or an application-level identifier carried in the payload - and skip or overwrite rather than re-apply anything it has already seen. The key point is that deduplication is the consumer's responsibility under QoS 1; the protocol delivers at least once and leaves it to the application to make at least once behave like exactly once where that matters.
This is not a heavy burden for most telemetry, but it does have to be a conscious design choice rather than an afterthought. A system that assumes each message is unique and processes every arrival blindly will, sooner or later, double-count a value when a real network hiccup causes a retransmission. Designing consumers to be idempotent from the start means those inevitable duplicates pass through harmlessly instead of quietly corrupting data during exactly the moments of network trouble when correct behavior matters most.
Whether a duplicate actually matters depends entirely on what the value represents. For an instantaneous measurement - a current pressure, a temperature, a tank level - a duplicate is essentially harmless, because processing the same reading twice just writes the same current value again. The second copy carries no new information and does no damage. This is the common case for a great deal of SCADA telemetry, and it is why at-least-once is comfortable for most real-time monitoring: the latest value simply overwrites, duplicate or not.
The dangerous case is anything cumulative. A running counter, a totalizer, a flow volume, a pulse count, a billing meter - these are values where processing the same increment twice produces a wrong total, and the error persists. If a well's produced-volume counter double-counts a delta because a duplicate slipped through, the total is now overstated and stays that way. For values like these, either the consumer must deduplicate rigorously, or the data model should carry absolute readings rather than increments so that a duplicate overwrites instead of adds. A cloud SCADA platform such as Merobix ingesting MQTT telemetry from field gateways is built with this distinction in mind, treating instantaneous values and accumulating counters differently so that at-least-once duplicates do not corrupt totals.
Given that duplicates are manageable, many teams deliberately choose QoS 1 over QoS 2 even though QoS 2 guarantees exactly-once delivery. The reason is cost. QoS 2 achieves exactly-once through a four-part handshake per message rather than QoS 1's single acknowledgment, which means more round-trips, more state held on both ends, and more overhead - a meaningful penalty on constrained or high-latency links like cellular field connections. For telemetry that is either naturally idempotent or made so by an idempotent consumer, QoS 1 delivers the reliability that matters at a fraction of the overhead, so teams accept the occasional duplicate as the cheaper, simpler trade rather than paying for QoS 2 across every message.
Because QoS 1 guarantees at-least-once delivery. When a publisher sends a message but the acknowledgment (PUBACK) is lost on the way back, the publisher cannot tell whether the message arrived, so it resends it with the DUP flag set. If the original had in fact arrived, the receiver now has it twice. The duplicate is the expected result of guaranteeing delivery over an unreliable network.
The DUP flag marks a message as a retransmission - the sender is retrying a publish it already attempted rather than sending a fresh message. It signals that the delivery is a redelivery attempt. It is a hint about the send, not a standalone deduplication key, so a consumer still has to handle the possibility that it has already processed the same content and must deduplicate at the application level if that matters.
Because QoS 2's exactly-once guarantee costs a four-part handshake per message, versus QoS 1's single acknowledgment - more round-trips, more state, and more overhead, which is costly on constrained or high-latency links like cellular. When telemetry is naturally idempotent or the consumer is built to deduplicate, QoS 1 provides the reliability that matters far more cheaply, so many teams accept occasional duplicates rather than pay for QoS 2 everywhere.
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
Last reviewed: July 27, 2026. Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.