Why Does Home Assistant Memory Use Stay High After Work Completes?
Home Assistant memory can stay high because the process or host retains reusable pages after work, but a rising plateau across identical cycles can indicate an integration, add-on, or version-specific leak.
A backup, database task, reload, or update may increase resident memory and filesystem cache without immediately returning the graph to its previous level. Record the process, container, VM, swap, and host-cache views separately; repeat the same trigger; and judge the slope and service health rather than one snapshot.
Confirm Which Memory Number Is Staying High
Record Home Assistant process resident memory, container or VM usage, host available memory, cache, swap, and any cgroup limit at the same timestamps. A host graph that includes reclaimable cache answers a different question from the process resident set.
Check whether the visible job is actually complete by comparing its final log event, CPU activity, database I/O, and integration state. Background cleanup, indexing, retries, or add-on work can continue after the interface reports completion.
If process memory is stable and the host still has healthy available memory without swap pressure, observe through another normal cycle. If the process, swap, or OOM pressure continues rising, preserve the timeline and isolate the trigger.
Repeat the Same Workload and Read the Plateau
Run the same bounded job at the same data size two or three times, allowing a fixed quiet period after each run. Record the pre-work baseline, peak, post-work plateau, and whether the next cycle starts above the previous one.
A case of high memory after upgrades does not establish a current universal defect; it justifies comparing pre-upgrade and post-upgrade plateaus on the affected system.
A similar plateau that stabilizes without swap growth is usually an observation branch, not an emergency. A staircase that rises after every identical cycle, eventually slows the system, or approaches the limit requires isolation.
Isolate Core, Integrations, Add-ons, and Host Cache
Compare the Home Assistant process with each add-on or neighboring container, then use a controlled safe-mode or custom-integration exclusion test when available. Change one component per cycle and keep the original trigger identical.
Use integration-focused isolation and startup timing as clues, not proof that the slowest integration owns the memory.
If growth stops without custom integrations, re-enable them in groups until the slope returns. If add-on memory grows instead, repair that service. If only host cache grows while available memory remains healthy, do not impose a smaller limit merely to make the graph fall.
Apply the Matched Action and Reproduce Again
Update or disable only the confirmed component, reduce an unbounded workload, correct a database or logging loop, or adjust the container limit only after measuring its normal peak. Restart once as a validation gate, then repeat the original work; a reboot alone is not the fix.
The dependency analysis in the Home Assistant performance-ceiling model helps prevent storage or add-on pressure from being mislabeled as Core memory growth.
Stop when repeated cycles settle at a bounded plateau with no swap, OOM, or latency failure. Escalate with version, installation type, process and host metrics, trigger steps, safe-mode comparison, and a time-series graph when growth continues on a clean reproducible path.
Recommended products
Support & Tips
More to Read
How to Optimize Immich Database Connections for Concurrent Containers
Do not raise max_connections first. Measure Immich sessions, total every container's demand, preserve admin headroom, and tune only the proven bottleneck.
How to Prevent Duplicate Jobs or Imports in Immich
Separate repeated jobs from duplicate assets. Use one canonical ingestion path, control retries and path changes, then test re-entry on a small cohort.
How to Repair Immich After Its Database Volume Fills Up
Never delete PostgreSQL WAL to free space. Stop Immich writes, preserve database state, add safe capacity, recover PostgreSQL, then prevent recurrence.
