Home Assistant Not Responding: Recovery Mode, Safe Mode, and What Broke
Home Assistant won't load or went unresponsive. How to tell which mode you're in, read the logs, and check whether the update broke it.
Researched with AI assistance, reviewed and edited by Tapabrata Biswas.

In this article
- 01Recovery mode and safe mode are not the same
- 02How do I start safe mode when the interface won't load?
- 03What the logs say when nothing loads
- 04It broke right after an update
- 05One integration can take the whole thing down
- 06Individual devices show unavailable, but Home Assistant is fine
- 07The companion app says Home Assistant isn't responding
- 08It keeps happening and nothing explains it
- 09Power cuts and Indian homes
- 10What this post does not cover
- 11Sources
Before anything else: this covers Home Assistant, the open-source home automation software. If you're looking at an Apple Home accessory showing "No Response," that's a different problem with a different fix, and Apple's own support pages cover it properly.
Right. Home Assistant stopped answering.
The single most useful thing to establish first isn't what broke, it's whether Home Assistant put itself into recovery mode or whether it never started at all. Those look similar from the sofa and they mean opposite things, and most troubleshooting advice online treats them as the same thing.
Recovery mode and safe mode are not the same
Recovery mode is what Home Assistant enters on its own when something stops it starting normally, and safe mode is something you deliberately choose to test whether custom code is at fault.
The distinction matters because it tells you what you already know:
| Recovery mode | Safe mode | |
|---|---|---|
| Who starts it | Home Assistant, automatically | You |
| What it means | Startup failed | You're running a test |
| What loads | A minimal set of system integrations only, skipping everything you configured | Core plus built-in integrations, but no custom integrations, cards, or themes |
| What it proves | Your configuration has an error | Whether the fault is custom code or Home Assistant itself |
Home Assistant's documentation is direct about when recovery mode appears: it falls back to it only when something unexpected prevents a normal startup, such as a YAML syntax error, an invalid configuration option, or a core integration failure.

That's the shape of recovery mode. Most of the building is dark, and there's still enough light to climb the stairs and find what broke.
So if you're looking at a stripped-down Home Assistant that loaded but has none of your devices, you're in recovery mode and your config is broken. If you deliberately chose safe mode and the problem went away, the problem is a custom integration or a custom card, not Home Assistant.
Two different messages. Reading advice for the wrong one is how an evening disappears.
How do I start safe mode when the interface won't load?
Create an empty file named safe-mode in your Home Assistant configuration directory, and Home Assistant boots into safe mode on the next start.
That's the method worth remembering, because the other two need something you may not have. The UI route is Settings, then System, then Restart Home Assistant in the top right, then Restart Home Assistant in safe mode. From a terminal it's ha core restart --safe-mode.
Both of those assume you can reach Home Assistant. The file works when you can't, as long as you can get to the configuration directory over SSH, Samba, or by pulling the disk.
What the logs say when nothing loads
Two commands cover almost everything, and both work without the web interface:
ha core logsshows the Home Assistant Core logha supervisor logsshows the supervisor log
The second one is the one people forget, and it's often where the answer is. When Core won't start properly, the supervisor is the thing complaining about it. A 2026.1.0 thread on the community forum tracked a UI that wouldn't load down to a supervisor error, Object of type DockerMount is not JSON serializable, with the supervisor process sitting at 100% CPU straight after boot. Nothing in the Core log would have told you that.
One more, and it belongs before a restart rather than after: ha core check validates your configuration. There's an equivalent in the UI under the restart menu.
The reason that matters is a solved forum case where an instance would load neither the UI nor SSH. The cause was an empty entities list in the recorder configuration. One malformed block, total lockout. A configuration check before restarting would have caught it in seconds; afterwards it took the disk coming out.
It broke right after an update
Check whether the release broke it before you change a single thing, because in 2026 that's been a real possibility more than once.
The Home Assistant community forum carried connection and loading failures for 2026.1.0, 2026.2.1, 2026.2.2, and the 2026.3.4 to 2026.4 upgrade, along with a 2026.3.0 report where soft reboot stopped working and needed a full operating system reboot instead.
That isn't an argument against updating. It's an argument for two habits:
Wait longer than feels reasonable. Updates download, unpack, and install, and things are genuinely offline while that happens. One forum thread on 2026.2.2 ended with the system coming back on its own after several reboots. A machine that answers a ping but not the web interface may still be mid-update.
Take the backup before, not after. Every one of those threads resolved the same way for the people who had one: restore the version that worked. The users without a backup rebuilt from scratch.
If you're on unusual hardware, check that too. One report of a system dying after 2026.2.3 involved generic x86-64 bare metal, where the user restored 2026.2.3 and stayed there.
One integration can take the whole thing down
A single misbehaving integration can hang Home Assistant hard enough that the recovery tools themselves stop working.
The clearest documented case is Home Assistant Green after 2026.2.1, where the UI hung indefinitely while the system looked healthy from outside. Users traced it to one integration, entso-e. What makes that case worth knowing isn't the specific integration, it's what happened next: ha core restart --safe-mode timed out with "context deadline exceeded," and the factory reset hung during reinstallation.
The tools you'd reach for assume the core is responsive enough to receive a command. When it isn't, you're down to filesystem access, which means SSH if it still answers, or the disk in another machine if it doesn't.
Which is the honest argument for a backup you can restore without the running system's cooperation.
Individual devices show unavailable, but Home Assistant is fine
When Home Assistant loads normally and only some entities are dead, the problem is the integration or the device, not Home Assistant.
Start at Settings, then Devices and services, then the system logs, and look for errors naming the integration. Home Assistant's troubleshooting documentation says warnings from integrations and configuration options land in the logs, so the failing one usually names itself.
The pattern to watch for is a whole integration's entities going unavailable at the same moment, which points at the integration or the service behind it rather than at your devices. A GitHub issue from 2024 tracked exactly that shape, with every entity from one integration dropping after a version change.
If the dead entities are Matter or Thread devices specifically, that's a different diagnosis with different causes, and a Matter device that won't appear covers it. If everything loads but your automations stopped running, automations that stopped firing covers the run-mode trap that causes most of those.
The companion app says Home Assistant isn't responding
When the browser works but the phone app doesn't, the app is the problem rather than the server.
A documented example: version 2025.8.7 of the Android companion app produced white screens and long delays before loading, and it was fixed in 2025.9.1. During that window the browser worked fine for the same users, which is the tell.
One cause worth knowing because it's not obvious: the app tests connections to all configured servers when it starts. A stale second server entry from an old setup makes the app wait on something that no longer exists. Removing it fixed the delay for at least one user in that thread.
It keeps happening and nothing explains it
Repeated unexplained failures on a Raspberry Pi usually trace to the SD card rather than to Home Assistant.
Home Assistant writes to its database continuously, all day, every day. Standard microSD cards aren't built for sustained write activity of that kind, so they degrade, and a degrading card produces exactly the symptom this article is about: intermittent unresponsiveness with no clean explanation in the logs.
Losing power mid-write is the faster version of the same ending. If the card is being written to when the power goes, the card can be corrupted outright rather than gradually.
Which makes this the most useful hardware note in the article for anyone running on a Pi:
- Booting from an SSD removes the problem rather than delaying it
- A high-endurance card, the type sold for dashcams, lasts considerably longer than a standard one
- An undersized power supply causes its own failures, and voltage drop through a cheap cable is a real cause rather than a superstition
If your Home Assistant has needed a power cycle more than once and no log ever explains why, suspect the storage before you suspect the software.
Power cuts and Indian homes
A machine that loses power without warning is running the SD-card corruption risk above every single time, which changes the hardware maths here.
A UPS large enough to keep the Home Assistant machine and the router alive through a short cut is doing two jobs: keeping the system up, and letting it shut down properly instead of being interrupted mid-write. For a Raspberry Pi or a small mini PC the draw is low enough that even a modest UPS covers it.
The other habit worth having is knowing that Matter and Thread devices legitimately take time to come back after an outage, since mains-powered devices return before battery ones re-establish their connections. Devices showing unavailable for a while after a cut is expected. Devices still unavailable an hour later is not.
What this post does not cover
This is about Home Assistant the software becoming unreachable, unresponsive, or stuck. It doesn't cover Apple Home accessories showing "No Response," which is an unrelated problem despite the identical wording, and it doesn't cover first-time installation, which is in installing Home Assistant.
Advanced recovery like rebuilding a corrupted database, migrating between installation types, and network-level debugging of remote access are out of scope here. So is anything specific to the dashboard, which the dashboard changes in 2026 covers separately.
Nothing here is a recommendation to buy specific hardware, and restoring a backup will roll back changes made since it was taken.
Sources
- Recovery mode, Home Assistant documentation
- General troubleshooting, including safe mode, Home Assistant documentation
- Troubleshooting your configuration, Home Assistant documentation
- Common tasks, Home Assistant Operating System, Home Assistant documentation
- Home Assistant 2026.7 release notes, Home Assistant, 1 July 2026
Frequently asked questions

Written by
Tapabrata Biswas
Tech Researcher
I test AI productivity tools and research home-automation gear the way most people use them. Not in a lab, but on an ordinary desk with an ordinary internet connection. The only test that matters: does it save you time?
Share the Post with Your Besties
Get the plain-English tech brief
One email a week on AI tools and smart-home tech. No jargon, no hype.


