MQTT GUIDE
3 min readMQTT Last Will and Testament (LWT)
The Last Will and Testament (LWT) is a message a client registers when it connects; if the client disconnects unexpectedly, the broker publishes that message on its behalf. It’s how MQTT signals that a device dropped off ungracefully.
A device that loses power or drops its connection can't announce that it's gone — it's simply silent. MQTT's Last Will and Testament (LWT) solves that by having the broker speak for a client that disconnects unexpectedly.
How Last Will works
When a client connects, it can register a will as part of the CONNECT packet: a topic, a payload, a QoS level,
and a retain flag. The broker holds onto it. If the client then disconnects ungracefully — an I/O error,
a keep-alive timeout, or the connection dropping without a proper
DISCONNECT — the broker publishes the will message on the client's behalf. A clean
DISCONNECT suppresses the will and removes it from the session.
Will delay (MQTT 5.0)
MQTT 5.0 adds a will delay interval: the broker waits a configured number of seconds before publishing the will. If the client reconnects within that window, the will never fires. This is what keeps a brief cellular flap or a quick restart from raising a false "device offline" alarm.
The presence pattern
The most common use of LWT is presence detection, and it pairs naturally with
retained messages: a client publishes a retained online to a status
topic when it connects, and registers a will that publishes a retained offline to the same topic. Subscribers
always see the current state, and the broker flips it to offline the instant the client vanishes.
Last Will in TBMQ
TBMQ supports Last Will messages, including the MQTT 5.0 will-delay interval and retained wills. When a connection times out on keep-alive, TBMQ closes it and publishes the client's will if one was set; a session takeover by the same client ID also publishes the will, unless the displaced client set a will-delay interval and the new connection resumes its session — in which case the pending will is cancelled. See the Last Will guide for the full behavior and configuration.
Frequently asked questions
What is the Last Will and Testament in MQTT?
A message a client hands to the broker when it connects — a topic, payload, QoS, and retain flag. If the client later disconnects ungracefully, the broker publishes that message on its behalf, letting the rest of the system know the client dropped off.
When does the broker publish the Last Will?
On an ungraceful disconnect: an I/O error, a keep-alive timeout, or the network connection closing without a proper DISCONNECT packet. A clean DISCONNECT does not trigger the will — the broker discards it instead.
What is the will delay interval in MQTT 5.0?
It tells the broker to wait a set number of seconds after an ungraceful disconnect before publishing the will. If the client reconnects within that window, the will is never sent — which prevents false alarms from brief network flaps.
How is Last Will used for presence detection?
Pair it with a retained status topic. The client publishes a retained "online" on connect and registers a will of retained "offline". Any subscriber then sees the current state immediately, and the broker flips it to "offline" automatically if the client vanishes.
Does reconnecting with the same client ID trigger the will?
It depends on the will delay. Without a will-delay interval — the default, and always the case in MQTT 3.1.1 — a takeover closes the old connection ungracefully and the broker publishes its will. Only if the displaced MQTT 5.0 client set a will-delay interval and the new connection resumes the session before it elapses does the broker cancel the pending will instead.
Run it yourself
TBMQ is a free, open-source MQTT broker built to scale. Spin it up in minutes or try the live demo — no install required.