Why Does Home Assistant Rebuild Different State After a Container Restart?
A Home Assistant container restart can make the system look briefly different even when the persistent configuration is perfectly intact. The reason is that a running instance contains both durable state on disk and transient runtime state in memory. Restarting the container destroys the latter and asks integrations to rebuild it.
This is why an entity can pass through unknown or unavailable, an MQTT device can reappear as soon as retained messages arrive, and an external service can remain missing until its retry succeeds. The restart is a state-reconstruction event, not simply a pause and resume of the same in-memory process.
The Container Runtime Is Replaceable; /config Is the Durable Boundary
Home Assistant Container is normally operated by recreating the container image while keeping the configuration mount. Updating the image, changing the runtime, or restarting the process should not require rebuilding the household from scratch when the persistent path remains attached correctly.
The current Home Assistant Container workflow explicitly recreates the container when changing versions. That model works because application state is expected to survive outside the disposable runtime.
Anything that exists only in process memory disappears at restart. The next process has to reread configuration, registries, databases, and integration inputs before it can recreate the same live view.
Core Starts a New Runtime State Machine
On each start, Home Assistant builds a fresh Core process with a new event loop, State Machine, services, timers, and integration runtime objects. The entity registry can identify known entities, but the current value of a physical device still needs to be restored, fetched, or reported.
Recorder also creates a new recorder run every time Home Assistant starts. Historical database rows persist, but the current process is a new runtime interval rather than a continuation of the old one.
This distinction matters when comparing logs or database timestamps around restart. A history record proves what Home Assistant previously observed; it does not automatically prove that the new process has already re-established the live device connection.
Integrations Repopulate Runtime State at Different Speeds
Some integrations reconnect to a local device immediately. Others wait for DNS, a broker, a cloud API, a radio bridge, or another container. Their entities therefore become available at different times even though Home Assistant Core itself is already running.
Home Assistant's current setup-failure model requires temporarily unavailable integrations to enter a retry path so they can recover when the device or service becomes reachable. That means the visible state after restart can evolve for minutes without implying that persistent data changed.
A second restart after every dependency is already warm can look much faster than a full stack restart because the network, broker, database, and devices no longer have to converge at the same time.
MQTT Makes State Reconstruction Especially Visible
MQTT is a useful example because the broker may retain discovery or state messages independently of the Home Assistant process. When Home Assistant reconnects, retained data can be replayed and entities can regain a last reported value quickly.
The MQTT integration documents that discovered entities are unavailable after restart until discovery is processed, while retained discovery and retained state messages can be replayed as subscriptions are rebuilt. Home Assistant also emits a Birth message that devices can use to republish discovery and fresh state.
A retained value is still a last-known report, not proof that the physical device is currently reachable. Availability topics and fresh telemetry should be evaluated separately.
Restart Behavior Depends on Where the Source of Truth Lives
- Persistent config and registries: reread from durable Home Assistant storage.
- Current device state: often fetched or reported again by an integration.
- MQTT state: may be rebuilt from retained messages or new publishes.
- Cloud-backed state: depends on remote API connectivity and credentials.
- Historical state: remains in Recorder but is not the same as live state.
- Pure runtime objects: are recreated by the new Home Assistant process.
The ZimaSpace explanation of MQTT state after reboot shows one specific reconstruction path. The broader rule is that restart behavior follows the location of each component's source of truth.
FAQ
Does restarting the Home Assistant container delete history?
No, not when the persistent configuration and Recorder database are mounted correctly. Restart replaces the runtime process; historical data remains in the persistent database.
Why can an entity show its old value immediately after restart?
The value may come from a Home Assistant restore mechanism, an integration cache, a retained MQTT state, or an immediate device poll. Check the integration and availability path before treating the displayed value as a fresh physical reading.
Recommended products
Tech & AI HUB
More to Read
Runtime State vs Persistent State in Home Assistant: What Must Survive Restart?
Home Assistant does not persist every live value; config, registries, selected restored states, history, and deployment data play different restart roles.
How Does Home Assistant Authenticate Local and Remote Sessions?
Local and remote Home Assistant sessions use the same server-side identity model; remote access changes the route and TLS boundary, not the core token...
Why Can Home Assistant History Queries Slow as Recorder Data Grows?
Recorder growth can raise History query cost when the requested range touches more rows, cache misses increase, or storage and index work become slower.
