Troubleshooting
Problem-first guide
Home Assistant keeps going offline
Use this when Home Assistant itself, remote access, integrations, bridges, or exposed devices keep looking offline.
Find the layer that failed before resetting everything.
Only use gear when it matches the confirmed missing role.
When Home Assistant keeps going offline, split the server from the smart-home devices first. A dead dashboard, a cloud remote-access error, a broken integration, and a Zigbee bridge outage are different problems even though they can all look like "Home Assistant is offline."
Fast split: if the Home Assistant web UI is unreachable on the local network, check host power, storage, Ethernet/Wi-Fi, and the router lease. If the UI works but devices are unavailable, keep the server alone and troubleshoot the integration, bridge, protocol mesh, or ecosystem link.
Start with what is actually offline
| What you see | Most likely layer | Best next move |
|---|---|---|
| The local dashboard will not load from a phone or laptop at home. | Host power, storage, network address, Ethernet/Wi-Fi, router DHCP, or the machine running Home Assistant. | Check the host, router lease, local IP, and whether the device is reachable before touching automations or integrations. |
| The dashboard works locally, but remote access or the app says offline. | Remote access, DNS, VPN, cloud relay, certificate, or phone network path. | Keep local Home Assistant running and fix the remote path separately. |
| Only Zigbee, Z-Wave, Matter, or Thread devices are unavailable. | Coordinator, bridge, add-on, USB path, protocol mesh, Matter controller, or Thread border-router reach. | Restart or inspect the bridge/coordinator path before rebooting the whole server or resetting endpoints. |
| Alexa, Google Home, or Apple Home fails while Home Assistant still controls devices. | Voice assistant exposure, entity sync, cloud integration, bridge, or duplicated room graph. | Treat the assistant as a control surface and repair exposure/sync after confirming Home Assistant is healthy. |
| One integration or device family is unavailable after an update. | Integration API, credentials, vendor cloud, local discovery, or breaking changes in that integration. | Rollback only if needed, but first check logs, credentials, network discovery, and whether native control still works. |
Use the local dashboard as the boundary
The local Home Assistant UI is the boundary between infrastructure failure and smart-home-layer failure. If the local UI is dead, focus on the host and network. If the local UI is alive, stop rebooting the server and follow the failed integration or control path.
- Server unreachable: check power, storage health, Ethernet, DHCP reservations, and the actual local address.
- Server reachable, devices unavailable: check the bridge, coordinator, add-on, integration logs, and whether the native app still sees the device.
- Server reachable, assistants confused: repair Alexa, Google, Apple, Homebridge, or cloud exposure rather than resetting working devices.
- Remote only fails: troubleshoot remote access separately from the smart-home control layer.
Do not make Home Assistant own every failure
Home Assistant can be the right automation brain, but it should not become the default suspect for every offline state. Bridges, vendor integrations, radio coordinators, voice assistants, and Wi-Fi policy can each fail while Home Assistant itself is fine.
Gear to consider only if the diagnosis points there
Disclosure: As an Amazon Associate I earn from qualifying purchases. These picks are here only when buying the right gear is actually part of the fix.
Home Assistant Green
Best for: homes where the current Home Assistant host is the proven unstable layer
- Purpose-built entry Home Assistant hardware
- Good fit when the server platform is the weak link, not just one integration
Watch out: Do not replace the host until local reachability, storage, network, and integration-specific failures are separated.
Home Assistant SkyConnect / Connect ZBT-1
Best for: Home Assistant homes where Zigbee or Thread coordinator ownership is the missing role
- Targets the coordinator layer rather than the whole server
- Useful when radio devices fail but Home Assistant is otherwise reachable
Watch out: Check current naming, firmware, and whether you actually need a new coordinator before buying.
Common Questions
Why does this kind of failure keep coming back even after basic fixes?
Because a lot of smart-home failures are shared-layer problems rather than one-time glitches. If the pattern keeps returning, follow the shared failure-layer guide instead of treating each device as a separate mystery.
How do I know whether this is Wi-Fi, protocol, or cloud trouble?
Batch failures often point to Wi-Fi or router policy, while one protocol family failing points more toward architecture. Use Wi-Fi load and protocol guidance to separate those layers cleanly.
What should I check before replacing hardware?
Check whether the house already has overloaded Wi-Fi, weak 2.4 GHz settings, or an unclear hub role. Replacements work better after the control and network layers make sense.