When a remote device goes silent, the hard question is whether it is fine and simply quiet or whether it has dropped off the network. MQTT answers this with the Last Will and Testament: a message a client hands the broker at connection time, to be published on the client's behalf if it disappears ungracefully. This guide explains how a last will is registered, how the keepalive mechanism detects a dead client, and how the will plus keepalive form the foundation of Sparkplug's birth and death certificates.
MQTT Last Will and Testament (LWT) in one line: A Last Will and Testament (LWT) is a message an MQTT client specifies when it connects, telling the broker to publish that message to a chosen topic if the client disconnects ungracefully - for example by dropping off the network. The broker detects the loss through the keepalive mechanism and then publishes the will automatically, giving other systems fast notice that the client has failed. If the client disconnects cleanly, the broker discards the will unsent.
A client sets up its last will as part of the connect exchange, before any normal publishing begins. It tells the broker three things: the topic the will should be published to, the payload the will should carry, and delivery options such as the QoS and whether the will should be retained. The broker holds this will quietly for the duration of the session and does nothing with it as long as the client behaves. The will is a contingency, armed at connect and waiting for the client to vanish.
The trigger is the keepalive mechanism. At connection, the client and broker agree a keepalive interval, and the client is expected to send at least some traffic - a real message or, failing that, a small ping - within that interval. If the broker hears nothing from the client for longer than the agreed grace period, it concludes the client is gone and considers the connection dead. Detection is therefore not instant; it takes until the keepalive window lapses, so a shorter interval means faster detection of a dropped device at the cost of slightly more overhead from pings.
Crucially, the will fires only on an ungraceful disconnect. If a client sends a proper disconnect message before closing, the broker treats the departure as intentional and discards the will without publishing it - the client left on purpose, so there is nothing to announce. The will is published only when the client disappears unexpectedly: a lost network, a crashed device, a yanked power supply. That distinction is exactly what makes the will meaningful, because it signals genuine failure rather than a planned shutdown.
Without a mechanism like this, detecting a dead remote device is guesswork. A subscriber that simply stops receiving updates cannot tell whether the device failed or whether its values just happen not to have changed, especially for slow-moving process points. Waiting long enough to be sure would mean a long blind window during which an operator has no idea a site has gone offline. The last will removes that ambiguity by producing a positive signal of failure rather than an absence of data.
For a remote RTU on a cellular or satellite link, a common pattern is to register a last will on a status topic. While the RTU is healthy it publishes an online status, and it arms a will that publishes offline to the same topic. If the RTU drops off - loses power, loses signal, or crashes - the broker detects the silence through keepalive and publishes the offline will automatically. Any system watching that status topic learns within roughly the keepalive window that the site has gone dark, without having to infer it from missing telemetry.
For a cloud SCADA such as Merobix, this is the difference between a fast, explicit dead-node indication and a slow, uncertain one. When a remote device's will fires, Merobix can flag that site as offline and alert operators promptly, rather than leaving stale values on the screen that look live. Pairing the will with a retained status is especially effective: the broker then always holds a current online-or-offline value for each device, so even a newly connected client immediately sees which remote sites are up and which have dropped, and the will keeps that status honest the instant a device fails.
Sparkplug is a specification layered on top of MQTT that standardizes how industrial devices publish data, and it leans directly on the last will to manage device lifecycle. In Sparkplug terms, when a device or edge node comes online it publishes a birth certificate - a message that announces it is present and, importantly, defines the set of metrics it will report so consumers know exactly what to expect from it. The birth certificate turns a bare connection into a described, understood participant.
The counterpart is the death certificate, and this is where the last will does the work. A Sparkplug edge node registers its death certificate as its MQTT last will when it connects, so if the node drops off ungracefully, the broker publishes that death certificate automatically through the ordinary LWT mechanism. The keepalive detection and will publication that MQTT already provides are exactly what Sparkplug needs to guarantee that a vanished node is reliably announced as dead, without any custom heartbeat logic bolted on top.
This birth-and-death pairing gives a Sparkplug consumer a clean, unambiguous model of who is present. A birth certificate says a node is online and here is what it publishes; a death certificate, delivered via the last will, says that node has failed. For a cloud SCADA such as Merobix consuming Sparkplug data, this means the platform can track exactly which edge nodes and devices are currently alive, react immediately when one dies, and know each device's metric set from its birth message - all built on the same last-will and keepalive foundation that plain MQTT provides, promoted by Sparkplug into a formal, standardized lifecycle.
Only when the client disconnects ungracefully - for example by losing its network connection or crashing without sending a proper disconnect. The broker detects the loss through the keepalive mechanism after hearing nothing for longer than the agreed interval, then publishes the will. If the client disconnects cleanly with a disconnect message, the broker discards the will unsent.
It depends on the keepalive interval agreed at connection. The broker waits until it has heard nothing from the client for longer than that window before declaring the connection dead and publishing the will, so detection is not instantaneous. A shorter keepalive means faster dead-node detection at the cost of slightly more ping traffic; a longer one is lighter but slower to notice a failure.
Sparkplug registers a node's death certificate as its MQTT last will, so the ordinary LWT mechanism publishes it automatically when the node drops off ungracefully. Combined with the birth certificate a node publishes when it comes online, this gives consumers a reliable online and offline lifecycle for each device, built directly on MQTT's existing keepalive and will features.
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.