After a broker or Home Assistant restart, it's tempting to take the first MQTT message as a sign that everything is back. Usually, it isn't. A client can reconnect while an entity is still unavailable. A retained state may be old, and an automation can be enabled without receiving the event it needs.
A birth message gives you a defined marker: a client has connected and published a known payload. It doesn't tell you whether the whole system is healthy. This guide uses a small lab topic to check three things: whether Home Assistant reconnected, whether a known publisher reconnected, and whether a harmless automation observed the event. The result covers only the controlled path you test. It doesn't prove that a NAS, sensor, network, or production automation has recovered.
The client behind the announcement
MQTT is a publish/subscribe protocol. A publisher sends a message to a topic, and the broker delivers it to clients with matching subscriptions. The protocol defines how messages are routed. It doesn't define what a payload such as online, ready, or homeassistant means for a particular product. Topic names and payload values are configuration, not universal diagnostics. The MQTT 5.0 specification is the reference for topics, subscriptions, retained messages, sessions, and connections.
The Home Assistant MQTT integration has settings for a birth message and a last-will message. That birth message belongs to the Home Assistant MQTT client. Its publication tells you about that client's connection and configured message. It doesn't tell you whether every other MQTT client received it, acted on it, or has valid data. Home Assistant's MQTT integration documentation describes these settings and how they relate to broker connectivity.
Be clear about which client each observation concerns. A message on homeassistant/status may describe Home Assistant, while a device-specific availability topic may describe a particular publisher according to that device's configuration. A broker log may show a connection. These facts can support each other, but none can stand in for the others.
One reversible test path
Use a broker and Home Assistant instance that you administer. Pick a new lab topic, such as lab/reconnect-check-2026-10-27, rather than a topic that controls a real device. Keep credentials, private addresses, commands, and personal identifiers out of it.
Before restarting anything, write down the exact details of the test:
- The Home Assistant birth topic and payload as configured in the MQTT integration.
- The lab topic and payload a known test publisher will use after it reconnects.
- Whether each message is retained.
- The entity or helper that will record the observation.
- The expected order of events and the clock you will use for comparison.
This record helps you avoid a common mistake: recognizing a value but attributing it to the wrong source. The broker can deliver a retained message to a new subscriber because it has stored that message. That's useful for state, but it doesn't necessarily mean someone published a new message after the restart. Change retain settings only in the lab path, and clean them up when you're done.
Separate observations of Home Assistant and the publisher
First, check that Home Assistant connects to the broker and publishes its configured birth message. Use the broker's own log or subscribe to the exact configured topic. Record the time, topic, payload, and received retain flag, and record the publisher's retain configuration separately. The dashboard alone isn't enough to establish the result.
Next, reconnect one known lab publisher and have it publish a distinct test payload to the lab topic. Observe that message independently. If the publisher sends a device-discovery configuration, check that Home Assistant has created the intended entity before using its state as a reconnect signal. Home Assistant documents MQTT discovery separately from the underlying broker connection. Its discovery documentation makes the distinction between configuration publication and state publication: they're separate events.
If either observation is missing, compare spelling, case, topic hierarchy, authentication, and retain behavior before restarting more services. A broad restart can obscure the order of events that would have explained the problem. Change one variable. Then repeat the small test.
An automation for recording the event
Once both test messages appear in the expected order, add a temporary automation to record the lab publisher's reconnect. A state trigger observes an entity's state transition; an MQTT trigger observes a message on a configured topic. Choose based on the fact you want to observe, even if you're more familiar with the other trigger. Home Assistant's automation trigger reference explains both trigger families.
For the first run, make the action a persistent notification, logbook entry, or helper value. Don't restart services, switch power, publish to a command topic, or change network configuration. Reconnect the lab publisher once, then inspect the automation trace. Home Assistant's automation troubleshooting guide distinguishes between a trigger that didn't fire and a condition or action that didn't complete.
The trace confirms only the configured rule's path. It doesn't prove that a real device finished its own recovery. If a notification appears twice, investigate before adding a delay or retry. There might have been two connections, a retained message, duplicate automations, or a repeat from the publisher.
Availability and the reconnect marker
An MQTT entity can expose an availability state based on a configured availability topic. It's often useful to compare that state with a reconnect marker, but they answer different questions. A client can reconnect while a device still reports unavailable. A retained offline state can remain until a publisher replaces it. The MQTT sensor documentation describes state and availability as distinct configuration paths.
Put the observations in a short table in your notes instead of trying to combine them in your head: Home Assistant birth observed, lab publisher message observed, entity availability, and automation trace. Include a time and source for each entry. Record what you observed, without assigning a cause. An example entry, if supported by your observations, is ‘Publisher reconnect observed at 10:03.’ “The device is healthy” may not be.
DeviceShelf Server can expose network observations to a Home Assistant installation you administer through MQTT discovery. That gives you an additional observation to compare with broker and service records. It doesn't establish why a client reconnected, guarantee a device's availability, or confirm that an automation action succeeded. Keep that observation separate from the restart marker.
Test cleanup and the next check
When you're finished, disable or remove the temporary automation and lab topic configuration. Clear any retained test data you created, and verify that no test message can trigger a real action. Keep the topic names, payloads, timestamps, broker observation, and trace result, but don't retain any secrets.
A useful result is narrow: Home Assistant published its configured birth message, one known lab publisher reconnected and published its test message, and one harmless automation recorded that event. If a part is missing, investigate that part first. Get the lab path repeatable before deciding whether a production automation needs a separate recovery check.