Home Assistant 2026.9 “Could Not Load Home Assistant”: Safe Recovery Checklist

Quick answer: If Home Assistant shows “Could not load Home Assistant” after a 2026.9 update, do not immediately reinstall or delete the database. First determine whether the failure is limited to the browser, the frontend, the network path, or Home Assistant Core itself. Test the local IP address, check Core and Supervisor logs, preserve a backup, and only then consider a rollback or restore.

This guide is designed as a safe diagnostic sequence. The same message can be caused by several different failures, so there is no single universal fix. A recent public issue report describes the message after upgrading to Home Assistant 2026.9.0, but that report alone does not prove that every occurrence has the same cause.

Two-minute triage

1. Open Home Assistant through its local IP address, for example http://192.168.1.50:8123, instead of a bookmark, reverse proxy, or cloud URL.
2. Try a private or incognito browser window. If that works, clear only the stored site data for the Home Assistant address rather than clearing the entire browser.
3. Try a second device on the same local network.
4. If the Companion App fails but a browser works, reset the app’s frontend cache and confirm its internal URL.
5. If no local device can connect, inspect Core, Supervisor, host, and network status before changing configuration.

Step 1: Separate a frontend problem from a Core problem

A browser error does not necessarily mean Home Assistant Core is down. The frontend can fail to load because of stale cached JavaScript, a custom dashboard resource, a reverse-proxy error, an invalid certificate path, or an address that no longer points to the correct host.

Use three tests:

• Local IP works, external address fails: investigate the reverse proxy, DNS, certificate, Cloudflare tunnel, or router forwarding.
• One browser fails, another works: investigate browser storage, cached frontend files, extensions, or an old pinned shortcut.
• Every local client fails: move to Core, Supervisor, and host diagnostics.

Step 2: Confirm the machine is reachable

Check the router’s client list and confirm that the Home Assistant machine still has the expected IP address. A DHCP change can make an old bookmark fail even when Home Assistant is healthy. Reserve the address in the router after access is restored.

If you use Home Assistant OS and can reach the local console, check that the host has an address and that the Core container is running. Useful read-only commands include:

ha network info
ha core info
ha supervisor info
ha core logs

Do not publish logs without removing tokens, public IP addresses, email addresses, device identifiers, and location information.

Step 3: Read the first meaningful error, not the last repeated error

Repeated reconnect messages are often symptoms. Look earlier in the log for the first exception after startup. Record:

• Home Assistant Core version
• Home Assistant OS or Container installation type
• Supervisor version
• Whether the failure began immediately after an update
• The first integration or component named in the traceback
• Database, disk-space, memory, or port-binding errors

Common branches include a custom integration failing during startup, a database migration taking longer than expected, insufficient storage, a reverse-proxy configuration error, and a frontend resource that is incompatible with the new release.

Step 4: Check storage and database health

A nearly full disk can prevent updates, database writes, log rotation, and container startup. If the host reports critically low free space, remove obsolete backups or unused add-on data through supported interfaces. Do not delete database files simply to regain access.

If the log mentions a malformed SQLite database, follow a database-specific recovery process and preserve copies before making changes. A slow database migration can also make the frontend appear unavailable; repeatedly cutting power during that work increases risk.

Step 5: Isolate custom integrations and frontend resources

If the problem began immediately after an update and the log names a custom component, check that component’s release notes and issue tracker. Disable only the named component when you have a backup and a reversible method. Do not remove the entire custom_components directory as a first response.

For dashboard failures, test the default Overview dashboard. A broken custom card can stop a particular dashboard from rendering while the rest of Home Assistant remains functional.

Step 6: Check reverse-proxy and URL settings

If local access works, the Home Assistant update may be unrelated to the external failure. Verify that the proxy still sends WebSocket traffic, preserves the correct host, and points to the current local address and port. Compare the browser’s error with the Home Assistant HTTP logs.

Do not add broad trusted_proxies ranges just to make an error disappear. Trust only the actual proxy address or narrowly required subnet. An overly broad trusted range weakens the protection against spoofed forwarding headers.

Step 7: Restart once, then stop repeating restarts

A single controlled Core restart is reasonable after logs have been collected. Repeated restarts can hide the first error, interrupt migrations, and make troubleshooting harder. If Core repeatedly becomes unavailable, preserve the logs from one complete startup cycle.

When a rollback is appropriate

Consider rollback only when all of the following are true:

• The failure started directly after the update.
• Local access and logs indicate a Core regression rather than a network or browser problem.
• You have a recent backup from before the update.
• You understand that restoring a backup also restores its older configuration and database state.

Prefer Home Assistant’s supported backup restore workflow. If the current patch release contains a confirmed fix, updating forward may be safer than returning to an older release. Review the release notes and the relevant issue before deciding.

Do not do these things first

• Do not reinstall Home Assistant before preserving backups and logs.
• Do not delete home-assistant_v2.db unless the logs identify database corruption and you have a recovery copy.
• Do not expose port 8123 directly to the internet to test connectivity.
• Do not paste access tokens or complete diagnostics into public forums.
• Do not assume every “Could not load” screen is the same 2026.9 bug.

Decision tree

1. Does the local IP work? If yes, troubleshoot the external URL, proxy, DNS, or certificate.
2. Does another browser work? If yes, clear site-specific browser data and inspect extensions.
3. Is Core running? If no, inspect Core and Supervisor logs.
4. Is the disk nearly full? If yes, free space safely before another update attempt.
5. Does the first traceback name a custom component? If yes, check that component’s compatibility and disable only that component.
6. Did the failure begin exactly with 2026.9 and survive local/browser checks? Preserve a backup and compare the active issue reports before rolling back or updating forward.

Information to collect before asking for help

• Exact Core, Supervisor, and OS versions
• Installation type
• Local versus external access results
• First relevant traceback with private information removed
• Available disk space
• Whether custom integrations are installed
• Whether the problem persists on a default dashboard

Sources and status

This guide uses a current public issue report as an incident signal, not as proof of a universal defect: Home Assistant Core issue #181212. For backup and recovery procedures, use the current Home Assistant backup documentation. Check the issue and release notes for changes before applying version-specific advice.

Last reviewed: September 23, 2026. Troubleshooting guidance may change as Home Assistant publishes patch releases.

Additional evidence-based diagnostics

Check the HTTP path without changing it

Use a browser developer network panel only to observe the first failed request. A 401 or 403 points toward authentication or proxy policy; a 404 toward an incorrect path or stale frontend asset; a 502 or 504 toward the proxy-to-Core path; and a browser certificate error toward TLS. Record the status and URL, but do not publish tokens or query strings.

Distinguish startup delay from a crash loop

After an update, database migrations and integration setup can extend startup. Watch Core status and logs instead of repeatedly restarting. A single long startup that completes differs from a process that exits and restarts. For a crash loop, capture the first exception in each cycle and the exit reason.

Use Safe mode only as evidence

If Home Assistant offers Safe mode and it loads, the frontend and core platform are capable of starting with custom integrations and custom frontend resources restricted. That result makes custom code a stronger suspect; it does not identify which component failed. Re-enable components selectively after reviewing logs and backups.

Check custom dashboard resources

A custom card or JavaScript module can break one dashboard after a frontend update. Open the default Overview dashboard directly and inspect browser console errors. Update or disable only the named resource. Avoid deleting dashboard storage or all HACS content as a broad test.

Inspect authentication state

If the login page loads but the interface fails after authentication, compare a private window, another user, and the same local URL. Repeated failed logins, an incorrect system clock, or proxy header problems can affect sessions. Do not disable authentication or widen trusted networks.

Evaluate storage pressure

Check free space, database size, backup accumulation, and host I/O errors. Free space through supported backup and add-on interfaces. Preserve recent backups externally before removing old local copies. Filesystem errors or recurring read-only remounts require storage replacement or host repair, not repeated Core restarts.

Expected-result matrix

Local IP success with external failure confirms Core is reachable and shifts attention to DNS, proxy, TLS, or tunnel. Safe mode success shifts attention to custom code. Core running with frontend asset errors points to browser or resource delivery. Core repeatedly stopping points to the first backend exception or host resource failure.

Recovery verification

After a fix, load the login page and dashboard from a clean browser session, confirm live entity updates, open Settings and Logs, restart Core once, and retest the intended external path. Verify that the canonical configuration remains secure and that no emergency bypass is left enabled.

Escalation evidence

Provide Core, Supervisor and OS versions, installation type, the exact time and first exception, local-versus-external results, disk availability, and whether Safe mode loads. Redact tokens, public addresses, coordinates, camera endpoints, device identifiers and personal account data.

Testing disclosure

Troubliq has not reproduced every 2026.9 failure environment. The workflow combines official recovery practices with the cited public incident report and treats that report as evidence of one occurrence, not proof of a universal release defect.

Related Troubliq resources

Use the Home Assistant Error Decoder to match the exact message, then review the current Home Assistant problems hub for related verified guides.

Advanced interpretation and recovery

Browser console interpretation

A failed JavaScript chunk with an old hashed filename often indicates cached frontend assets. A blocked WebSocket after successful HTML delivery points toward proxy upgrade handling, authentication or network policy. Repeated 401 responses point to session state; 404 responses for custom-card resources point to dashboard dependencies. Capture only the error type and resource name, not authentication headers.

Installation-type branches

On Home Assistant OS, use the local console, Supervisor and supported backup tools. In Container, inspect the container state, logs, volume mounts and image version without using Supervisor commands. In Core environments, inspect the Python service and virtual environment. Applying commands for the wrong installation type can create a second failure.

Update-forward decision

Before restoring, read the current patch release notes and the cited issue status. A fixed patch preserves newer database state and is often safer than rollback. Update forward only after a backup and only when the fix matches the observed component or symptom; a generic newer version is not proof of relevance.

Rollback decision

Rollback is justified when the previous version was stable, the failure begins immediately after updating, logs support a regression, and a compatible pre-update backup exists. Record configuration changes made since that backup. Restoring also rolls back database history and configuration, so preserve the current backup separately.

External-path verification

When local access works, test DNS resolution, certificate hostname and expiry, proxy health, upstream address, WebSocket upgrade and firewall rules. Change one layer at a time. Do not expose port 8123 publicly, disable TLS verification, or trust a broad network range to make a diagnostic test pass.