Dashboards Slow and laggy since 2025.6.0(1)
The problem
Since the update to the 6.0 and also 6.1 my dashboards are very laggy, sometimes displaying a value is also empty. Most of the time I have to wait up to 30sec until graphs are displayed. CPU and Memory Usage seems OK. When I do a fresh restart, it is OK for a while, but after some time it lags again
What version of Home Assistant Core has the issue?
2025.6.1
What was the last working version of Home Assistant Core?
2025.5.X
What type of installation are you running?
Home Assistant OS
Integration causing the issue
No response
Link to integration documentation on our website
No response
Diagnostics information
No response
Example YAML snippet
Anything in the logs that might be useful for us?
Additional information
No response
can confirm the issue. every page that has a history graph causes 40% cpu load for me and takes forever to display the graph
Yes, right. I checked while redering the graphs. CPU peaks above 80% sometimes
I can confirm same issue... Pages which have multiple mini-graph-card with 24h history do not load...
Changed the title since it seems to afffect dashboard with graphs only. Thinking about reverting back, cause its really annoying
For me it seems to occur on dashboards with apexcharts cards.
on Apex as well, but mainly on the HA standards
Same here with 24hr history graphs. Also the Energy Dashboard sometimes doesn't load or at least loads very slowly.
seems to be that it is not a rendering issue, rather than db query performance
I have noticed the same issue.
I am really not getting any further with that. Most of my dashboards are practically unusable. I added Ram and CPU Power to the virtual machine running HA. CPU Load and Memory load is lower, but it has no effect on the loading times of the dashboard. The only hint I get so far is this warning in the logs: Logger: homeassistant.components.recorder.util Quelle: components/recorder/util.py:292 Integration: Recorder (Dokumentation, Probleme) Erstmals aufgetreten: 15:13:56 (1 Vorkommnis) Zuletzt protokolliert: 15:13:56
The system could not validate that the sqlite3 database at //config/home-assistant_v2.db was shutdown cleanly
+1 Mainly history card doesn't load recent values when opening. Those load after a while (next sensor update?!) I also use the history Explorer card. That one load normally
It is not related to database... I use MySQL and is same thing... Adding CPU do not help because looks like only one core is used... Same thing I saw when Im restore backup that only one core has been used... But this is maybe related to "unsupported" version of installation(VM+Supervised installation)...
I use the full Hass OS on a VM. Why do you think its unsupported?
I suffer from the same issue, running HAOS on Pi. So no VM involved
Small illustration. Here a history card with 4 temp sensors just after opening:
And the same card about 30 seconds later:
Edit: I noticed this only seem to happen for history cards populated via a filter in auto entities. That worked till core 2025.5. Since 2025.6 this only works when I hard code the entities. Via auto entities that long delay occurs Raised an issue in auto entities as well: https://github.com/thomasloven/lovelace-auto-entities/issues/553
I have the same issue with refresh dashboard pages. After update to 2025.6.1 all pages have long time to show up. Some times is longer 5x than before update.
I have noticed the same issue.
I have the same problem - all graphs and calculated values are terribly slow.
It is really frustrating. I went through the change logs, but I couldnt really pinpoint what could be the root cause of the issue. Without that its hard to contact the respective dev. Perhaps anyone else has an idea, what could cause the issue.
The service get_statistics was added. Maybe there are related changes in the recorder
I'm having this same issue with my config-template-card/picture elements dashboard. Works perfectly on 2025.5.3, but gets bogged down in 2025.6.0 and 2025.6.1.
Hey @Hypfer we think your change 142602 is causing quite some issues for many users. Could you look into that?
https://github.com/home-assistant/core/pull/142602
Thanks
Respectfully, I don't see how random people with zero credibility believing something is supposed to be my problem. This is not corporate. Hence, corporate style communication is unsuited for this space.
That said, feel free to take a look at the commit and come up with a hypothesis of how the actual code change could lead to the observed behavior.
"Something changed in the recorder" is good enough of a heuristic to go checking, however, it is not good enough of a proof to ping some random other person in the way that just happened.
Edit: Now on a computer, I could fully parse the previous comments that are
It is really frustrating. I went through the change logs, but I couldnt really pinpoint what could be the root cause of the issue. Without that its hard to contact the respective dev.
And
The service get_statistics was added. Maybe there are related changes in the recorder
So there is no evidence and you admit that there is none, but then suddenly, an idea how to make it someone else's problem appears and suddenly it's
we think your change 142602 is causing quite some issues for many users.
Maybe.. not do that? Especially when there is like a paper trail three comments further up?
Well Hüpfer, its really not nice to get rude and unfriendly. We went through the changes and this is the only thing we saw, which could be related. If you had spend less time in a humble answer like, "No, thats not from my change", or a as experience dev give us even hint, that is something the community could benefit from.
You spent a lot of time quoting and firing at me. I think we could use that time more wisely
It might have nothing to do with the service @Hypfer created: when calling it directly from the developers tab, the result is almost instant. What I do see however is that the request for the statistics is queued for ~11.5 seconds (Firefox developer tools), and the console show a lot of messages like Received event for unknown subscription 181. Unsubscribing..
Maybe someone from the HA frontend team can help with this?
@houthacker it is just speculating, but I can imagine changes where made to facilitate the new service. The new service works, but changes probably caused unforeseen delays for i.e. the history card. Funny is that the custom history explorer card is not effected!
AFAICT the changes in the PR are 100% related to the new service and no existing code is changed. So only if something calls the new service it could have an effect.
The problem is even bigger than I thought. As rigthly speculated here I can confirm that it affects all my statistical elements. Even those where I do not display a chart:
If I click on those entities, after they loaded after ca. 30s, I get permanently the following:
One thing is strange, although it says entity not available, the values show up in the long term statistics (after 30s loading)
One more thing puzzles me, obviously not all users seem to be affected. Anyone an idea how to proceed from here?
Honestly, the extent to which 2025.6.x breaks my HA instance versus how little it seems to be impacting others is quite puzzling indeed. I don't use graphs or statistics like many others in this thread seem to, but something in the update brings all of my dashboards to a grinding halt, with long load times and cards that never even appear, and I don't even know where to begin to troubleshoot. I have picture elements cards embedded in a config template card (which gets reevaluated each time one of several entities update), and a simple-swipe-card that contains custom button cards that appear when certain conditions are met. The config template card loads eventually, but the simple-swipe-card containing my custom buttons is completely missing from my dashboard (with no error messages indicating an issue). Everything works fine after rolling back to 2025.5.3. Happy to create another GitHub issue if my issue is unrelated to this, but I thought maybe the root cause was the source of all of our issues.
I've noticed this with 2025.6.x as well. Whenever I pull up any dashboard with graphs there is some serious lag before the screen populates. I have one particular page with 3 standard sensor cards showing 24 hours of history and every once in a while it will trigger a database lock and my CPU goes up and my whole instance becomes unresponsive until I restart the container. Like others have stated, I'm not sure if they are related but I figured I'd add my own observations. Going back to 2025.5.3 fixes the issue so it does seem specific to this version.
2025-06-18 08:54:40.400 ERROR (PyrateLimiter's Leaker) [root] Uncaught thread exception
Traceback (most recent call last):
File "/usr/local/lib/python3.13/threading.py", line 1041, in _bootstrap_inner
self.run()
~~~~~~~~^^
File "/usr/local/lib/python3.13/site-packages/pyrate_limiter/abstracts/bucket.py", line 195, in run
asyncio.run(self._leak(self.sync_buckets))
~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.13/asyncio/runners.py", line 195, in run
return runner.run(main)
~~~~~~~~~~^^^^^^
File "/usr/local/lib/python3.13/asyncio/runners.py", line 118, in run
return self._loop.run_until_complete(task)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^
File "/usr/local/lib/python3.13/asyncio/base_events.py", line 719, in run_until_complete
return future.result()
~~~~~~~~~~~~~^^
File "/usr/local/lib/python3.13/site-packages/pyrate_limiter/abstracts/bucket.py", line 177, in _leak
leak = bucket.leak(now)
File "/usr/local/lib/python3.13/site-packages/pyrate_limiter/buckets/sqlite_bucket.py", line 118, in leak
count = self.conn.execute(query).fetchone()[0]
~~~~~~~~~~~~~~~~~^^^^^^^
sqlite3.OperationalError: database is locked
EDIT: I found that the database locking issue seems related to a combination of using a conditional card with custom expander card on the masonry layout and not with this particular issue on historical data. Converting the page to sections seemed to resolve my issue, strangely enough.