Home Assistant frontend stuck on loading screen after 2 weeks of stable work (Pi 5 + NVMe)

[geraatolstjak (geraa)]

Hello everyone! I’m really enjoying Home Assistant overall and how easy it is to customize, but there are some stability issues that need to be fix.

Hardware / setup
• Raspberry Pi 5, 4 GB RAM
• Argon Mini V2 case
• NVMe M.2 SSD
• Home Assistant OS

Background
The system worked perfectly for about two weeks with this exact setup. No changes, no experiments, no heavy add-ons. Then the UI suddenly became inaccessible.

Problem description
I’m currently unable to access Home Assistant reliably.
• Remote access via Nabu Casa opens the URL, shows the Home Assistant logo, and then hangs on a white screen. The frontend never finishes loading.
• When I’m at home and try local access, I get the same stuck loading screen.
• The only way I managed to access the UI locally was via an incognito browser window. Normal browser sessions don’t load.
• This worked only temporarily.

After the issue appeared, I manually rebooted the system.
After that:
• I was able to access Home Assistant once via Nabu Casa remotely.
• Local access still worked only in incognito mode.
• After some time, the problem returned again.

What I already tried / changed
Based on advice I found, I added recorder limits to reduce load and database size:

recorder:
purge_keep_days: 7
commit_interval: 30

However, I currently don’t have a keyboard and mouse connected to the Pi, so I can’t access the host directly to:
• restart Home Assistant safely from CLI
• delete or reset the database files
• inspect logs locally

Because of that, I’m effectively locked out of recovery actions.

Integrations / system load
The setup is intentionally very lightweight:
• Broadlink + SmartIR (only for AC control)
• Zigbee2MQTT:
• Aqara temperature sensors
• Aqara door/window sensors
• No heavy add-ons
• No large dashboards
• No experimental integrations

That’s why this is confusing: the system is small, but the frontend completely breaks.

Current behavior
• index.html loads (logo appears), but the frontend never initializes.
• Both Nabu Casa and local access fail in the same way.
• Clearing cache doesn’t help.
• Incognito worked once, then stopped being a reliable workaround.

Question
What are the most likely root causes for this kind of behavior on a Pi 5 + NVMe setup after ~2 weeks of stable uptime?

Is this more likely:
• frontend / websocket failure
• corrupted recorder database
• memory pressure on Pi 5 (4 GB)
• NVMe / filesystem issue
• something specific to Nabu Casa timing

And what is the safest recovery path if I currently don’t have physical access to the device?

At this point the system feels UI-bricked despite being a very light installation, and I’m trying to understand what actually failed.

[tom_l]

@geraatolstjak

The only way I managed to access the UI locally was via an incognito browser window.

This means Home Assistant is up and running but you have a problem viewing it. There are no stability issues that need to be rectified (well there are, but they are not causing your issue).

All you need to do is clear your web browser and/or mobile Companion app frontend cache.

Search the forum for how to do this for your specific mobile (Android or iOS). For most web browsers ctrl+shift+r will do it.

You will often need to do this when a new frontend version is released.

[geraatolstjak (geraa)]

Hello, thank for your answer!

I already cleared browser cache, site data and history (both mobile and desktop).
After doing that, the situation became worse — now I cannot access Home Assistant at all, including incognito mode.

This suggests the issue is not frontend cache related.

Important details:
• Incognito mode initially worked, which already ruled out cache
• After cache/history cleanup, access is completely gone
• Logo loads, but frontend never initializes
• Same behavior via Nabu Casa and local access

This looks like a backend / websocket / database or filesystem issue, not a browser problem.

What would be the next backend-level diagnostic or recovery step in a situation where UI access is no longer possible

[tom_l]

@geraatolstjak

Incognito mode initially worked, which already ruled out cache

If incognito mode works that definitely points to a cache issue.

The fact that it is no longer working points to another issue.

Connect a keyboard and display to the pi and view the logs with this command:

ha core logs

[geraatolstjak (geraa)]

What is happening
After a reboot everything looks normal. Home Assistant starts, the UI loads, integrations work.
After roughly ~20 minutes the system consistently starts to degrade:
• the UI becomes slow or stops loading
• saving YAML or reloading configuration sometimes fails
• shortly after that the UI becomes inaccessible
• the console starts spamming filesystem and I/O errors
• eventually the filesystem is remounted read-only and HA is unusable until the next reboot

Errors seen on the console
These messages repeat continuously once the issue starts:
• Buffer I/O error on device nvme0n1p3
• EXT4-fs error (device nvme0n1p3)
• journal has aborted
• failed to get inode
• lost sync page write
• Remounting filesystem read-only
• Input/output error

This clearly looks like a block device / filesystem failure rather than a Home Assistant configuration problem.

Hardware
• Raspberry Pi 5 (4 GB)
• Case: Argon v2 with NVMe support
• Storage: Kingston NV2 M.2 NVMe SSD (250 GB)
• Official Raspberry Pi 5 power supply

Cooling concern
The case is Argon v2 with NVMe support, and I’m not fully confident the fan is actually spinning, even though it is connected to the correct GPIO pins. And I also add termo pad for m2 and now it installed tightly.

The behavior is very time-based: cold boot → works → ~20 minutes later errors start. This strongly suggests a thermal or power-related issue.

Initial suspicion vs current conclusion
At first I suspected a software issue — specifically Broadlink, because disabling its updater temporarily improved UI stability.
However, after seeing repeated EXT4 and I/O errors at the kernel level, I now strongly suspect this is an underlying hardware issue, not Broadlink or HA itself.

Context
Before switching to NVMe, I was running Home Assistant on a high-quality A2-rated microSD card, and that setup worked stably for about two weeks.
I migrated to NVMe specifically to improve long-term stability and reliability, but the opposite happened.

Questions
• Does this look like a typical failure pattern for a DRAM-less NVMe (Kingston NV2) under sustained small writes?
• Are there known thermal or reliability issues with Argon v2 + NVMe on Raspberry Pi 5?
• If I temporarily go back to a microSD A2 card, is that a reasonable workaround, and what kind of lifespan should I realistically expect under HA load?
• Would a USB SSD be a safer alternative than NVMe in this setup?

At this point I’m trying to determine whether the root cause is the SSD model itself, thermal management in the case, or the NVMe implementation on Pi 5

[MaxK (Mark)]

How to Troubleshoot Raspberry Pi Crashing

Please note the Suggested hardware in the installation instructions. Some users have found that a Pi 3 B is not sufficient to run Home Assistant. And 1 GB of RAM is not enough to run Home Assistant. What does the Green and Red light mean? Ensure you are using an appropriate power supply. See the warning at the top of this page: USB peripherals directly attached to the Pi can exceed the power supply limits (for example SSDs and Disk drives). Use the Raspberry Pi Power Supply Checker In…

SD Card Reliability

There are recommendations on this forum and elsewhere to avoid using SD cards because they are not reliable (e.g., they wear out). Device manufacturers typically measure reliability, under ideal conditions, as meantime between failure (MTBF) for harddisks or the total number of write operations for SDs and SSDs. They also compete on other metrics including speed, storage capacity, price, size, etc. so you can usually find this information if you search for it. SD cards may not be able to do as…