When a telemetry gateway drops off an MQTT broker, the broker faces a question: should it remember this client and hold onto the messages meant for it, and if so, for how long? MQTT version 5 answers this precisely with two controls - the clean start flag that decides whether to resume or reset a session, and the session expiry interval that puts a clock on how long a disconnected session survives. This guide explains what these two settings do, how they govern the queued messages waiting for a flapping gateway, and why they replaced the coarser all-or-nothing model of earlier MQTT.
MQTT session expiry in one line: In MQTT 5, clean start is a flag the client sets on connect that decides whether the broker resumes an existing session or discards it and starts fresh, and session expiry interval is a timer that sets how long the broker keeps a disconnected session and its queued messages before deleting them. Together they control whether a reconnecting gateway picks up where it left off, including any messages queued while it was offline, or comes back with a clean slate.
An MQTT session is the state the broker holds on a client's behalf: its subscriptions, and any messages that need to be delivered to it and have not yet been acknowledged. While a client is connected, this state is obviously in use. The interesting behaviour is what happens when the client disconnects, expectedly or not. If the broker keeps the session, then when the client returns it does not have to re-subscribe, and any messages that arrived on its subscriptions while it was away can be delivered to it, so it misses nothing. If the broker throws the session away, the client comes back to nothing and must start over.
Persisting a session is what lets a client survive a disconnection without losing data. For a subscriber that must receive every reading, a held session means the broker queues the messages that arrive during the outage and hands them over on reconnect, so the gap in connectivity does not become a gap in data. This only applies to messages sent at a quality of service that guarantees delivery; the mechanism exists precisely to honour that guarantee across a disconnection rather than dropping messages the moment the client vanishes.
The cost of remembering is resources. Every retained session consumes broker memory and, if messages are queuing up, storage, and a broker serving a large fleet cannot keep every session for every client that ever connected forever, especially for clients that may never return. That tension - remember enough to survive a real reconnect, but do not hoard state for clients that are gone for good - is exactly what MQTT 5's two controls exist to resolve.
Clean start is a boolean the client sets when it connects. Set true, it tells the broker to discard any existing session for this client and begin a brand-new one, so the client starts clean with no leftover subscriptions or queued messages. Set false, it tells the broker to resume an existing session if one is still present, so the client picks up its subscriptions and receives whatever was queued while it was away. Clean start therefore governs the behaviour at the moment of connecting: fresh slate, or continue where I left off.
The session expiry interval governs what happens after the client disconnects. It is a duration the client can specify saying how long the broker should keep the session alive once the connection ends. If the client reconnects within that interval, the session is still there to resume; if the interval elapses first, the broker deletes the session and its queued messages, and a later reconnection starts fresh regardless of the clean start flag. A value of zero means the session ends immediately on disconnect, while a large value asks the broker to hold the session for an extended period.
The two work together. A client that wants to survive a brief outage connects with clean start false and a session expiry interval long enough to cover the expected disconnection, so a quick drop-and-reconnect resumes cleanly with all queued messages delivered. A client that wants no history connects with clean start true. The important advance over earlier MQTT is that the expiry interval is a timed value chosen by the client, rather than the old binary choice between a session that vanished instantly or one that persisted indefinitely.
Field gateways on cellular and radio links flap - they drop and reconnect as signal fades, as the process cycles, or as the carrier hiccups - and how the broker handles those flaps decides whether the telemetry stream survives them intact. With a sensible session expiry interval and clean start false, a gateway that drops for a minute reconnects to a session the broker was holding, receives any commands or messages that were queued for it during the gap, and carries on without loss. The flap becomes a non-event rather than a hole in the data.
Choosing the interval is a balance tuned to the link. Set it too short and a gateway that stays down slightly longer than expected loses its session and any queued messages, turning a recoverable outage into a data gap. Set it too long and the broker holds sessions and queued messages for gateways that may be gone for hours, consuming resources and stockpiling stale messages that may no longer be worth delivering. The right value reflects how long a realistic outage lasts and how much queued data is still useful once the gateway returns - long enough to ride out normal flaps, not so long that it hoards state for the genuinely dead.
For a cloud SCADA platform such as Merobix, this timed model is what lets the messaging layer behave sensibly across the unreliable links that field sites live on. A gateway that flaps should resume its session and catch up on what it missed, while a gateway that has been offline for a long stretch should not leave the broker indefinitely holding a growing pile of undelivered messages. The MQTT 5 controls give exactly that nuance - resume the recoverable, expire the abandoned - so the platform stays resilient to short outages without paying an unbounded cost for long ones, which the older all-or-nothing session model could not express.
Clean start is a flag set when connecting that decides whether the broker resumes an existing session or discards it and starts fresh at that moment. Session expiry interval is a timer set for after disconnection that decides how long the broker keeps the session before deleting it. Clean start controls the behaviour on connect; session expiry controls how long a session survives while the client is away.
Earlier MQTT offered only a binary clean session flag: either the session vanished the instant the client disconnected, or it persisted indefinitely with no way to put a limit on it. MQTT 5 splits this into clean start, which controls resuming versus starting fresh on connect, and a session expiry interval, which is a timed duration the client chooses for how long a disconnected session is kept. The key advance is the timed expiry, letting a session outlive brief outages without persisting forever.
Long enough to cover a realistic outage on its link so a normal drop-and-reconnect resumes the session and delivers any queued messages, but not so long that the broker hoards state and stale messages for a gateway that may be gone for hours. The right value depends on how long typical disconnections last and how long queued data stays useful. Too short risks data gaps on longer outages; too long wastes broker resources on abandoned sessions.
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.