HA is "running", but web interface is unresponsive

I’m running HA standalone (via HassOS) on an x64 Beelink mini pc.

It’s been pretty stable for months, but the past couple of days, the web page refuses to connect (http://homeassistant.local:8123) spins for a while and times out, while the observer page (http://homeassistant.local:4357) is responsive and shows

Home Assistant observer
Supervisor:	Connected
Support:	Supported
Health:	Healthy

The CLI is also responsive, and I tried restoring from backup and rebooting, to no avail. :frowning:

Do I have to reinstall from scratch?

Is there a way to diagnose what the actual failure is?

ha supervisor logs and ha core logs aren’t terribly informative, but I don’t really know what I’m looking for.

1 Like

Http or https?
What IP addresses are allocated to your HomeAssistant server? Router? Device you are attempting to access your HomeAssistant observer page from?

Any VMs, VLANs, or custom docker installs? Any PiHole or firewall software?

Slow internet connection? Unreliable?

Any timeout or attempt unsuccessful entries in your system log?

Is your time/date correct?

Have you waited long enough for the updates to complete?

Did you by any chance upgraded the Watchman Integration to v0.8.1 a couple of days ago? If so THIS might help.

So the restore from backup didn’t succeed? :thinking:

1 Like

As I said, even local access (e.g., http://homeassistant.local:8123) doesn’t work. There are no other VMs; it’s running HassOS standalone.

The internet connection is fine, and irrelevant, since it doesn’t work on the LAN, much less the internet.

Date and time are fine; it’s contacting the correct time server.

I’ve left this machine running for days now, and it’s been completely inaccessible at all times.

I can access the keyboard/monitor, and the cli works OK via JetKVM, so I can collect logs; sharing them is annoying because there’s no obvious way to put the logs somewhere I can share them. The log outputs here are collected via OCR and are… 80% correct?

The host logs show issues with docker trying to kill a container that doesn’t want to die, but the container ID doesn’t correspond to anything I can find:

e.g., host logs outputs this:

[2026-01-31 12:31:28.480 homeassistant dockerd[8151: tine="2026-01-31704:31:28.480643693-08:00" level=error msg="Handler for POST /v1.52/containers/fffcf3acdca3ac4ca7a35eeblf9a130972932e0386322a9b8614a976a61904072aafd7 restart returned error: Cannot restart container ffcf3acdca3ac4ca7a35eeblf9a130972932e0386322a9b8614a976a61904072aafd7: tried to kill container, but did not receive an exit event”

[2026-01-31 12:40:51.426 homeassistant dockerd[8151: tine="2026-01-31T04:40:51.426754931-08:00" level=info nsg="Container failed to exit within 4nZ0s of signal 15 - using the force” container=ffcf3acdca3ac4ca7a35eeblf9a130972932e0386322a9b8614a976a61904072aafd7

and I have no idea what ffcf...aafd7 corresponds to.

ha supervisor logs are full of copies of:

[33n2026-01-31 11:49:04.283 WARNING (sentry-sdk.BackgroundWorker) [urllib3.connectionpool] Retrying (Retry(total=1, connect=None, read=None, redirect=None, status=None)) after connection broken by ’NewConnectionError ("HttpsConnection(host=]
0427061 . ingest sentry. io’ , port=443): Failed to establish a new comection: [Errno 1111 Connection refused”)’ : /api/5370612 envelope

I restored, and it appeared to succeed, but didn’t fix anything.

I don’t use the Watchman integration, so that’s not the problem.

I suspect I’m going to have to install from scratch, which I’m not looking forward to; installation on x64 machines is a pain.

Please take a look HERE.

Yes, I saw that. It’s an old issue, and I suspect that these log entries are downstream of whatever’s keeping the main web site from connecting.

Check the available disk space on the HA Server. It may have run out of space.