The Last Will and Testament lets a broker announce that a client has dropped off, which is invaluable for knowing when a remote device has gone dark. On a stable network it fires when it should. On a flaky cellular link it can fire far too eagerly, marking a site offline for the few seconds it takes to reconnect after a brief drop, and generating a stream of false death and recovery notifications. MQTT 5.0 added the will delay interval to tame exactly this behaviour, by holding the will back to give a client a chance to come back first. This guide explains what the will delay interval is, how it interacts with the will and the session, and why it matters on unreliable field links.
MQTT Will Delay Interval in one line: The MQTT will delay interval is an MQTT 5.0 property that tells the broker to wait a specified number of seconds after a client disconnects before publishing that client's Last Will message. If the client reconnects and resumes its session within that window, the will is never sent, which prevents a brief disconnect from triggering a false offline or death notification.
Without a will delay, a broker publishes a client's Last Will as soon as it detects that the client has disconnected ungracefully, whether that is because a keepalive was missed, the network dropped, or the connection was severed. That immediacy is a feature when a device has truly failed, but it is a nuisance when the client is merely reconnecting. The will announces the client as gone at the very moment the client is often already dialling back in, so the offline state can be shorter than the notification that describes it.
The will delay interval inserts a grace period. When it is set, the broker notices the disconnect but starts a timer rather than publishing the will straight away. If the timer expires and the client still has not returned, the will is published as usual, confirming that the absence is real. If instead the client reconnects and resumes its existing session before the timer runs out, the broker cancels the pending will entirely, and no death message is ever sent. The subscribers watching that client's status never see a blip, because from their perspective the client never announced that it left.
The delay is expressed as a property carried in the will, alongside the will topic, payload, quality-of-service, and retain flag, so it is configured by the client when it connects. A client that knows it lives on an unreliable link can set a delay comfortably longer than its typical reconnect time, so ordinary reconnects fall inside the window while a genuine failure, which never reconnects, still eventually triggers the will after the delay elapses.
The will delay interval is closely tied to the client's session and its session expiry. For the delay to save a reconnecting client, the session must still exist when the client returns, so that the reconnection is a resumption of the same session rather than a fresh one. This is why the will delay works hand in hand with a non-zero session expiry: the session persists across the brief gap, the reconnecting client rejoins it, and the pending will is cancelled because the client that owned it is back.
There is a relationship between the two timers that a designer needs to keep in mind. If the session expiry is shorter than the will delay, the session can lapse before the will delay would have elapsed, and in that case the broker publishes the will when the session expires rather than waiting out the full delay, because the client's session no longer exists to be resumed. In practice this means the will delay is only fully effective up to the point at which the session itself would expire, so the two intervals are usually chosen together.
It is worth separating the two kinds of disconnect. A graceful disconnect, where the client sends a proper disconnect packet, does not trigger the will at all by default, because the client is leaving on purpose. The will and its delay are about ungraceful disconnects, the ones a device does not get to announce, such as a dropped modem or a power loss. The delay interval simply gives those ungraceful disconnects the benefit of the doubt for a while, on the theory that many of them are transient rather than terminal.
On remote industrial sites the link is frequently the least reliable part of the system. A cellular modem at a wellpad can lose and regain its connection several times an hour as it hands between towers, rides out interference, or recovers from a momentary signal drop. Each of those brief losses is an ungraceful disconnect from the broker's point of view, and without a will delay each one publishes a death notification followed moments later by a recovery, filling operators' screens and alarm logs with offline events for sites that never actually stopped working.
That noise is not harmless. When status flaps constantly, operators learn to ignore the offline indicator, and a genuine outage hides among the false ones. The will delay interval cuts this at the source by absorbing the short flaps entirely. If a site reliably reconnects within, say, a reasonable window, and the delay is set beyond that window, the everyday flaps produce no notifications at all, and an offline event on the screen once again means something real: a device that has been gone long enough to be worth a look.
For a cloud SCADA platform such as Merobix, where the status of many remote sites is watched centrally, this distinction between a flap and a failure is what makes the death notification trustworthy. Combined with a suitable session expiry so the session survives the gap, a well-chosen will delay lets the platform report a site as truly offline only when it has been unreachable past the grace period, rather than every time a modem hiccups. Operators get a status indicator they can believe, and the alarm history stops being polluted by the ordinary turbulence of cellular connectivity.
The keepalive determines how long the broker waits before deciding a silent client has disconnected in the first place. The will delay interval is a separate, later timer that determines how long the broker waits after that decision before actually publishing the will. Together they mean a client is not declared truly gone until it has missed its keepalive and then failed to return within the will delay window.
Choose a delay comfortably longer than the typical time it takes the device to reconnect after a brief drop, so ordinary flaps fall inside the grace period, but short enough that a genuine failure is still reported promptly. There is no universal value because reconnect times vary by modem, carrier, and location. The delay should also be set within the session expiry, since the session must still exist for a reconnect to cancel the pending will.
Yes. The will delay interval is a property introduced in MQTT 5.0 and is not available in MQTT 3.1.1, where the will is always published as soon as an ungraceful disconnect is detected. To use it, both the client and broker must support MQTT 5.0, and the client sets the delay as a property alongside the rest of its will configuration when it connects.
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.