How to Choose an MQTT QoS Level for Telemetry

Back to Blog

Match QoS to the Consequence of Loss

Start with one question per topic: if a single message on this topic is lost, what happens? For a pressure value published every few seconds, the answer is nothing lasting - the next sample carries the current truth and the gap is invisible on a trend. That is QoS 0 territory: fire and forget, no acknowledgement, lowest overhead. Spending round trips to guarantee a value that is about to be replaced is wasted effort.

For a value that is not superseded quickly - a daily totalizer reading, a state change, an alarm - loss matters, and QoS 1 guarantees at-least-once delivery. The refresher on what each level promises is in MQTT QoS levels 0, 1, and 2; this page is about choosing among them for real topics.

Decide Commands Separately From Data

Commands are not telemetry and deserve their own decision. A command that must not be lost but is naturally idempotent - a setpoint write where sending the same value twice is harmless - is a good fit for QoS 1. A command where a duplicate would cause a second, unwanted action - a pulse to open a valve, an incremented counter - is where QoS 2 earns its cost, because exactly-once delivery prevents the double action.

Be honest about idempotency before reaching for QoS 2. Most setpoints and absolute writes are idempotent and safe at QoS 1; only relative or edge-triggered commands truly need exactly-once. If your command topic carries absolute values, QoS 1 with application-level confirmation is usually the better engineering choice than paying for QoS 2 everywhere.

Weigh the Cost of Each Level on the Link

QoS is not free. QoS 0 sends one packet. QoS 1 adds an acknowledgement round trip and requires the sender to store the message until it is acknowledged. QoS 2 adds a four-part handshake for exactly-once semantics, the most round trips of the three. On a high-latency cellular or satellite link, those extra round trips slow throughput and drain the client's inflight budget.

This is why blanket QoS 2 hurts on field links: you pay handshake latency on every message including trend data that could have been fire-and-forget. Match the level to the topic and you spend round trips only where loss or duplication actually costs something. The duplicate behavior of QoS 1 specifically is worth understanding before you rely on it - see MQTT QoS 1 duplicate delivery.

Apply the Decision Table

Use this per-topic table as the default and override only with a reason. High-rate trend or sensor data superseded by the next sample: QoS 0. Values, states, and alarms that must arrive but tolerate a rare duplicate: QoS 1. Non-idempotent commands where a duplicate causes an unwanted action: QoS 2. Idempotent commands and setpoints: QoS 1 with an application-level readback.

Topic type	Loss impact	Duplicate impact	QoS
High-rate trend data	None, next sample replaces	Harmless	0
Totalizer, state, alarm	Value lost	Tolerable	1
Idempotent setpoint	Command lost	Harmless	1
Non-idempotent command	Command lost	Double action	2

Verify the Choice in Practice

After setting QoS per topic, confirm the subscriber actually receives at the guaranteed level and that your inflight window is not saturating on a slow link. If publishes back up when the link degrades, you may have set QoS higher than the link can sustain for that message rate - tune the inflight limit or lower QoS on the highest-rate topics.

Confirm duplicates are handled where you accepted QoS 1. At-least-once means the same message can arrive twice after a reconnect, so the consuming application must tolerate or de-duplicate it. If a duplicate would corrupt a total, that topic was mis-classified and belongs at QoS 2 or needs application-level de-duplication.

Common Mistakes

The dominant mistake is defaulting every topic to QoS 2 for a feeling of safety, then wondering why throughput collapses on a cellular link under the handshake load. The reverse mistake is QoS 0 on a totalizer or alarm, where a single lost message leaves a permanent gap.

A subtle one is using QoS 2 on an idempotent command that QoS 1 would have covered - you paid for exactly-once semantics you did not need. And do not forget that QoS 1's rare duplicate is a feature you accepted, not a bug: the consumer must handle it, or the topic was the wrong level.

Frequently Asked Questions