How to Set Up MQTT Last Will for Device Offline Detection

Back to Blog

Register the Will at Connect Time

The last will is configured in the CONNECT packet, not published later - the client hands the broker a topic, a payload, a QoS, and a retain flag, and the broker holds it. If the client disconnects ungracefully - a lost link, a crash, a keepalive timeout - the broker publishes that will on the client's behalf. So the will is your dead-man's switch: the device tells the broker in advance what to announce if it vanishes.

Point the will at a per-device status topic, with an offline payload, so each device has its own availability signal. Set retain on the will so a dashboard connecting later immediately learns the device is offline rather than waiting for the next event. The mechanism in full is in the MQTT last will and testament.

Publish a Matching Retained Birth Message

A will that announces offline is only half the pattern; you need something to announce online. Immediately after the client connects, have the device publish a retained online message to the same status topic the will targets. This birth message overwrites the retained offline value, so the status topic always holds the device's true current state - online after a successful connect, offline after the broker fires the will.

Both messages must target the identical status topic and both must be retained, or a dashboard connecting between events sees nothing or a stale value. The birth-and-will pair is a single coherent scheme: the device says online when it arrives and pre-arranges to be marked offline when it leaves. This is the same discipline Sparkplug formalizes - see the Sparkplug NBIRTH and NDEATH message.

Set the Will Delay to Avoid False Offlines

A brief network blip can make the broker fire the will even though the device is fine and about to reconnect, flickering the dashboard to offline and back. The will delay interval solves this: it tells the broker to wait a set period after the disconnect before publishing the will, giving the device a chance to reconnect first and cancel the pending will. Reconnect within the delay and no false offline is ever published.

Set the delay to cover your expected transient reconnect time but not so long that a genuinely dead device shows online for ages. It is a balance between false positives and detection speed. The knob and its behavior are covered in the MQTT will delay interval; tune it to the link's real reconnect behavior.

Tie Detection Speed to the Keepalive

The broker only fires the will after it decides the client is gone, and for an ungraceful disconnect that decision is driven by the keepalive - roughly one and a half keepalive intervals of silence. So your offline-detection latency is set by the keepalive, not the will. A long keepalive means a device can be gone for a while before the will fires and the dashboard updates.

Set the keepalive to the detection speed the operation requires, remembering the cellular constraints, then the will delay adds its wait on top. Together they define how fast and how reliably a device shows offline. Tune the keepalive with setting an MQTT keepalive for a cellular link so detection is neither sluggish nor jumpy.

Verify the Online and Offline Transitions

Test both transitions explicitly. Kill a device abruptly - pull power, not a clean shutdown - and confirm the status topic flips to offline after the keepalive and will-delay window, and that a dashboard connecting afterward reads offline from the retained value. Then bring the device back and confirm its birth message flips the status to online promptly.

Test the false-offline case too: briefly interrupt the link within the will delay and confirm the device reconnects before the will fires, so the status never flickers to offline. A birth-and-will scheme that survives both a real death and a transient blip without lying about either is the one that makes a fleet availability view trustworthy.

Common Mistakes

The most common mistake is setting a will but no birth message, so the status can go offline but never authoritatively back to online, leaving a device stuck offline on the dashboard after it recovers. The second is forgetting retain on either message, so a dashboard connecting between events sees no status at all.

Another is omitting the will delay, so every brief blip flickers the device offline and erodes trust in the whole availability view. And do not expect the will to fire on a clean disconnect - a graceful disconnect normally suppresses the will, which is correct, but means you must publish an explicit offline on planned shutdown if you want that state recorded.

Frequently Asked Questions