An MQTT-based dashboard can mark a device offline within seconds of losing its connection. That's useful, especially when the device normally keeps a persistent connection to the broker. But it's easy to read too much into the alert. An offline MQTT message alone doesn't prove that a NAS lost power, a service stopped, or the whole network went down.
These alerts often come from MQTT's Last Will and Testament feature, usually called LWT. It lets a client leave the broker a message to publish if the connection ends unexpectedly. This guide covers what that message tells you, how to test it without disrupting a working setup, and how to keep an automation's conclusions within what its input actually shows.
The connection event visible to the broker
An MQTT client can supply a will message with a topic, payload, quality-of-service setting, and optional retained flag. If the broker detects that the connection ended without a normal disconnect, it can publish that message for the client. The broker is reporting what happened to a client connection. It isn't checking every process or network interface on the device.
The MQTT Version 5.0 specification defines will messages and the conditions for publishing them. It also covers session and delay options that can affect when a subscriber receives a will. Those settings matter if you're using the alert to trigger a time-sensitive response.
A publisher might, for example, connect with an online birth message and an offline will. If Wi-Fi drops, the device loses power, or a network path fails, the broker may eventually publish offline. That's good evidence that the broker didn't receive the expected graceful disconnect from that client. It doesn't tell you which cause was responsible. Nor does it tell you the state of a file share, web interface, or storage volume on the same machine.
Before turning a topic into an alert, write down exactly what it tells you. “MQTT client connection was lost” is a narrow claim you can test. “NAS is broken” rolls several separate questions into one and needs more evidence.
Graceful stops and unexpected connection loss
An application can normally disconnect from a broker cleanly. Depending on the client configuration and protocol settings, that can prevent the broker from publishing a will. The will is meant to report an ungraceful connection loss; it isn't a general shutdown log. You can't reliably use it to tell whether someone deliberately stopped a service.
Keepalive affects the timing, too. MQTT clients and brokers use it to detect a connection that has gone quiet. The broker won't necessarily detect the loss at the instant someone unplugs a cable. The delay depends on the configured interval, network timing, and broker behavior. Record when the subscriber received the message; record the broker's detection time separately only when supported by broker logs. Will Delay, delivery delays, and retained-message replay can separate those times.
Home Assistant documents an MQTT integration with birth and last-will messages, along with availability topics for MQTT entities. Its availability documentation explains the distinction between an entity's current value and the connection signal used to decide whether that value is available.
An offline will can be retained. That may be useful when a new subscriber needs the last known availability state. There's a catch, though: a subscriber can receive a stored offline value when it starts. That message reports the last recorded state, which doesn't necessarily mean a new outage happened when the subscriber connected.
A controlled test topic
Run tests only on a broker and network you administer. Pick a separate, clearly labeled test topic instead of a production device-control topic or a wildcard subscription. Don't reuse a topic that drives a lock, switch, alert escalation, or any other physical action.
Set up a disposable client with an online birth message and an offline will. Use a second authorized client to subscribe, and record the topic, payload, subscriber receipt time, retained indicator, and configured keepalive. Stop the publisher normally first. Check whether the broker publishes the will. In a separate test, interrupt the client's network path or terminate its process abruptly so it cannot send DISCONNECT, then watch whether the subscriber receives the will and when it arrives.
Mosquitto's subscriber manual documents a command-line client you can use to watch a test topic. Its output shows which messages it received. That doesn't prove every other subscriber reacted or that the device itself is unreachable through another route.
Use clear test payloads that contain no sensitive information. A short value like test-online or test-offline is safer than a real hostname, private address, inventory data, token, or credential. If you use a retained will for the test, clear the retained test value after recording the result. That's good housekeeping, but it won't undo any copies a subscriber has already processed.
Independent checks for the question at hand
Choose an independent check based on what you would do with the result. To find out whether a NAS file service is reachable, test the documented service through an authorized path. To check whether the host rebooted, compare an uptime record or system log. For a possible Wi-Fi change, look at the network equipment's current association information. Each answers a different question from an MQTT connection event.
You can also have an automation wait through a short, documented grace period before sending a notification. After the grace period, notify only if the offline condition still holds. This cuts down on noise from brief Wi-Fi changes or broker restarts. It doesn't make LWT a health check. One useful condition might require both an offline will and no fresh publisher timestamp after the expected interval. Test the rule with an intentionally short interruption and an ordinary graceful stop, as well as a broker or subscriber restart.
Don't test by blocking unfamiliar devices or changing router settings on a live household network. A controlled test client gives you a clear result with less risk of disrupting an authorized user. If a production result surprises you, save the topic, time, payload, client identifier where appropriate, and broker logs before changing several settings at once.
Restart behavior and retained availability
Broker and subscriber restarts are normal. They can briefly interrupt connections or cause retained availability messages to appear. Before attaching a notification to a topic, restart the subscriber during a test window and check whether it receives a previously retained state. Then, when it's safe and authorized, restart the broker and watch how the publishers reconnect.
This matters for Home Assistant automations. A trigger that runs when Home Assistant reconnects can process a value that was already there before the restart. An arriving message needs to be evaluated; it doesn't automatically mean there's a new incident. If the publisher supports it, a timestamp, a monotonic counter, or a separately modeled availability state can make the rule more specific.
DeviceShelf Server can publish network observations to a Home Assistant installation you administer. Treat it as one input among others. Compare an MQTT event with the observation time and the relevant device or service record; it doesn't guarantee device identity, availability, or security. The server documentation describes the supported integration path.
Conclusions supported by the evidence
A reliable troubleshooting note after an alert can be short: “At this time, the subscriber received an offline message on the configured availability topic.” Record the independent check and its result separately. MQTT 5 also permits a client to deliberately request Will publication using DISCONNECT reason code 0x04, and retained delivery need not coincide with publication. This wording therefore establishes neither an unexpected disconnect nor the publication time.
That's the practical value of LWT: it gives a managed system a standard way to communicate an unexpected MQTT disconnect. With a defined topic, a bounded test, and an independent follow-up observation, it can help you decide what to check next. On its own, a received offline message can indicate a broker connection problem, but may also reflect deliberate Will publication or a retained state. It doesn't establish the state of the whole device.