MQTT QoS levels
Quality of Service is agreed per message. It decides how hard the sender and receiver work to make sure a message arrives, and whether it can arrive twice.
The three levels
| QoS | Name | Packets | Can be lost | Can be duplicated |
|---|---|---|---|---|
| 0 | At most once | PUBLISH | Yes | No |
| 1 | At least once | PUBLISH, PUBACK | No | Yes |
| 2 | Exactly once | PUBLISH, PUBREC, PUBREL, PUBCOMP | No | No |
QoS 0, at most once
One PUBLISH, no acknowledgement, no retry. If the connection drops while the packet is in flight, the message is gone. Cheapest on bandwidth and broker memory, and the right choice for readings that repeat often.
QoS 1, at least once
The sender keeps the message until it gets PUBACK and resends it, with the DUP flag set, if the acknowledgement does not arrive. The receiver can see the same message twice, so handlers should tolerate a repeat. Most state and command traffic runs at QoS 1.
QoS 2, exactly once
A four-packet handshake: PUBLISH, PUBREC, PUBREL, PUBCOMP. The message arrives once, at the cost of two more packets than QoS 1. Use it for commands that must not run twice.
Two rules that surprise people
- Delivery uses the lower QoS. The broker delivers at the lower of the publish QoS and the subscription QoS. Subscribing at QoS 0 turns every message into fire and forget, whatever the publisher chose.
- Only QoS 1 and 2 are queued for an offline client. With a persistent session (clean session false, or a session expiry interval in MQTT 5) the broker holds QoS 1 and 2 messages until the client returns. QoS 0 messages sent in the meantime are dropped unless the broker is configured otherwise.
Choosing a level
| Traffic | QoS | Why |
|---|---|---|
| Temperature every 5 seconds | 0 | The next reading replaces a lost one |
| Door opened, alarm triggered | 1 | Must arrive, a duplicate is harmless |
| Device state, availability | 1 | Usually retained too, so late subscribers get the last value |
| Command that is not idempotent | 2 | Running it twice does damage |
Seeing QoS on a live broker
MQTT Viewer shows the QoS of every received message and lets you pick it when publishing.
Frequently asked questions
What is the difference between QoS 1 and QoS 2?
QoS 1 resends until the receiver sends PUBACK, so a message can arrive more than once. QoS 2 adds a second handshake, PUBREC, PUBREL and PUBCOMP, so it arrives exactly once. QoS 2 costs two more packets per message than QoS 1.
Which QoS should sensors use?
QoS 0 for readings that repeat every few seconds, where a lost sample is replaced by the next one. QoS 1 for readings that are published rarely or drive alerts. QoS 2 is rarely worth it for telemetry.
Does the subscriber get the QoS the publisher sent?
The broker delivers at the lower of the publish QoS and the subscription QoS. A QoS 2 publish to a QoS 0 subscriber arrives as QoS 0.
Does MQTT QoS guarantee message order?
Within one topic and one session, QoS 1 and 2 messages are delivered in the order they were sent. Across topics, or after a reconnect with a new session, there is no ordering guarantee.
Are QoS 0 messages queued for an offline client?
Brokers queue QoS 1 and 2 messages for a persistent session while the client is away and drop QoS 0 by default. Mosquitto can queue QoS 0 too with queue_qos0_messages true.
Related reference: retained messages, MQTT ports and the MQTT cheat sheet.
MQTT Viewer is free and open source, and runs on macOS, Windows and Linux.
Download MQTT Viewer