Quick answer: If Home Assistant Core becomes unresponsive and the Supervisor watchdog restarts it several minutes later, collect one complete failure cycle before changing anything. Check memory, CPU, disk I/O, database activity, blocked integrations, recorder growth, and the first error preceding the watchdog action. A watchdog restart is the recovery event, not necessarily the root cause.
Public reports describe Core 2026.9 systems becoming unresponsive without an obvious out-of-memory event. Because many unrelated failures produce the same visible symptom, this guide uses a measurement-first process and avoids claiming a universal fix.
Preserve evidence before restarting
- Note the exact time the interface stopped responding.
- Save Core, Supervisor, host, and add-on logs covering several minutes before the event.
- Record Core, OS, Supervisor, and database versions.
- Record CPU, memory, disk utilization, free space, and database size.
- List integrations or add-ons changed immediately before the first incident.
Confirm what is actually unresponsive
Test the local IP address from a second device. If the interface fails but SSH, the observer, or host metrics remain available, the host may be healthy while Core is blocked. If the entire machine disappears from the network, investigate power, storage, hardware, virtualization, and host networking instead.
Build a simple timeline
- Last successful automation or state update
- First delayed or failed request
- First warning or exception in the log
- Time the watchdog detected failure
- Time restart began
- Time Core became available again
The first abnormal event is more useful than the final watchdog message.
Check memory without assuming an OOM
Look for steadily increasing memory, sudden spikes, swap pressure, and the host kernel’s out-of-memory messages. If memory remains normal, do not label the incident a memory leak. A blocked event loop, slow storage, database lock, integration timeout, or network filesystem can make Core appear dead without exhausting memory.
Check the Recorder database
A large or unhealthy database can create long writes, migrations, purges, and startup delays. Record the database engine and size. Look for locked, malformed, disk-full, and unusually slow query messages. Do not delete the database as a diagnostic shortcut.
Reduce unnecessary high-frequency entities only after identifying them. Broad exclusions can remove history you need and may hide the actual source.
Check integrations and add-ons
Look immediately before the freeze for an integration generating repeated exceptions, reconnect loops, or blocking calls. If one component is consistently named, investigate its current release notes and issue tracker. Disable only the suspected nonessential component with a backup and a reversible plan.
Add-ons are separate processes but can still saturate storage, CPU, memory, or network resources. Compare their resource graphs with the incident time.
Check storage and host health
- Confirm adequate free disk space.
- Check for filesystem or I/O errors.
- On SD-card installations, treat repeated I/O errors as a possible storage failure.
- On virtual machines, inspect host contention and storage latency.
- Confirm system time and network connectivity remain stable.
Controlled isolation
- Back up the current system.
- Choose the strongest single suspect from the logs.
- Change only that component.
- Observe long enough to cover the normal failure interval.
- If the freeze returns, restore the previous state and test the next evidence-backed suspect.
Changing several integrations, database settings, and network components together makes the result impossible to interpret.
Rollback or update forward?
If incidents began only after 2026.9 and no environmental change occurred, check later patch notes and the active issue report. Update forward when a patch explicitly addresses the condition. Roll back only with a verified pre-update backup and an understanding that database and configuration state will also move backward.
Do not do these things first
- Do not schedule automatic restarts to hide the problem.
- Do not disable the watchdog.
- Do not delete the Recorder database without diagnostic evidence.
- Do not remove every custom integration at once.
- Do not publish raw diagnostics containing secrets or personal data.
Decision tree
- Did the whole host disappear? Investigate hardware, storage, power, virtualization, and host networking.
- Only Core stopped responding? Inspect the first Core error and resource timeline.
- Memory climbed continuously? Identify the component correlated with the growth.
- Storage latency or database errors appeared? Protect the backup and diagnose storage or Recorder.
- One integration loops before every freeze? Isolate that integration reversibly.
- No local cause is visible and failure began with 2026.9? Compare the active issue and newer patch releases.
Incident reference
See Home Assistant Core issue #181318 for a current report of Core becoming unresponsive followed by a Supervisor watchdog restart. The report is a useful signal, but it does not establish one cause for every installation.
Last reviewed: September 23, 2026.
Additional evidence-based diagnostics
Measure event-loop symptoms
A blocked event loop can stop API and frontend responses while the host still answers. Look for warnings about blocking calls, integrations taking excessive setup time, executor saturation and long event-loop delays before the watchdog restart. Do not assume high CPU is required for Core to become unresponsive.
Correlate resource history
Compare CPU, resident memory, swap, disk latency, database writes and network errors across the minutes before the freeze. A value that rises after Core is already stuck may be a consequence. Prefer repeated correlations across two incidents before changing configuration.
Check Recorder workload
Recorder purges, repacks, migrations and high-frequency entities can create intensive storage activity. Record the database engine, size, purge schedule and relevant errors. Do not delete the database or broadly exclude entities until logs and timing make Recorder a credible suspect.
Inspect network-mounted dependencies
Integrations or backups that depend on an unavailable network share, DNS server or remote database can stall or retry. Compare network and resolver events with the freeze. Restore connectivity or disable only the proven nonessential dependency using a reversible change.
Review custom integration behavior
Repeated exceptions, rapid reconnect loops and synchronous calls from one custom integration can degrade Core. Confirm the component version and upstream compatibility. Disable only the strongest suspect after a backup, then observe for at least the normal interval between failures.
Separate add-on load from Core faults
Add-ons run separately but share host CPU, memory, disk and networking. A camera processor, database, backup job or log flood can starve Core. Compare add-on resource graphs and schedules with the timeline instead of removing add-ons indiscriminately.
Use the watchdog correctly
The watchdog restores availability when Core stops responding; it does not diagnose the cause. Keep it enabled. Automatic scheduled restarts can erase evidence and create the appearance of stability while the underlying lockup remains.
Build a controlled comparison
Change one variable, document it, and observe through the expected failure window. If the incident returns, reverse that change before testing the next hypothesis. Several simultaneous changes cannot produce reliable evidence and complicate rollback.
Validate durable recovery
Confirm Core remains responsive past the prior failure interval, entity timestamps remain current, automations execute, database writes continue, resource levels stabilize and one controlled Core restart completes without a new freeze.
Escalation package
Provide the complete version set, installation type, database engine, sanitized log window beginning before the freeze, resource timeline, watchdog time and changes already tested. Remove tokens, addresses, coordinates, camera URLs and personal entity names.
Testing disclosure
Troubliq has not reproduced every watchdog restart scenario. The article uses the cited upstream incident as a demand signal while keeping the diagnostic branches applicable to other measured causes; it does not assert that Home Assistant 2026.9 universally causes freezes.
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
CPU interpretation
Sustained CPU saturation before each freeze suggests a workload or loop, but a brief spike during restart is expected. Break usage down by Core, add-ons and host services. If one integration floods logs or state updates at the same time, isolate it rather than increasing hardware blindly.
Memory interpretation
Track resident memory and swap over hours, not only the value after restart. A monotonic increase associated with one integration supports a leak hypothesis. Stable memory during a freeze shifts attention toward blocking I/O, event-loop stalls, database locks or network waits.
Disk-latency interpretation
High I/O wait, filesystem errors or long database commits can make Core unresponsive without high CPU. Check the storage device and host logs. On flash media, repeated read/write errors justify immediate backup and storage replacement planning.
Database-engine branch
SQLite problems are diagnosed through Core logs, database integrity and host storage. External MariaDB or PostgreSQL adds network, server, connection-pool and authentication layers. Confirm which engine is active before applying repair commands. Preserve statistics and backups before database work.
Automation-load branch
A looping automation can generate rapid service calls and state changes. Inspect traces and logbook activity near the incident. Disable only the confirmed automation and verify whether the event rate and responsiveness normalize; do not disable all automations as a long-term workaround.
Template and sensor branch
Templates that update excessively or reference many entities can create work across the state machine. Compare recently changed templates and high-frequency sensors with the timeline. Optimize only measured hot paths so useful state history is not lost.
Network timeout branch
Cloud integrations, DNS failures and unreachable local devices can generate reconnect loops. Well-behaved integrations should not block Core, but custom components may. Correlate the first timeout and component logger with the freeze before disabling anything.
Backup-job branch
Backup creation, compression, upload and retention can stress storage and CPU. If incidents align with scheduled backups, test the job separately, inspect destination availability and reduce overlap with database maintenance. Never stop a backup by cutting host power.
Thermal and power branch
Throttling, undervoltage and unstable power can cause broad slowness or host resets. Check platform health indicators and hardware logs. Replace suspect power supplies or cooling using manufacturer guidance; software changes cannot repair failing hardware.
Virtual-machine branch
Inspect host contention, ballooning, storage latency, snapshots and CPU scheduling. A responsive hypervisor with a stalled guest suggests a guest resource or device problem; simultaneous issues across guests point to the host.
Expected-result interpretation
If disabling one proven custom component prevents recurrence past the normal interval, investigate that component upstream. If database repair removes I/O errors and writes remain stable, monitor Recorder. If the whole host still stalls, leave Core configuration intact and escalate to hardware or virtualization diagnostics.
Recovery documentation
Record the last incident time, root-cause evidence, exact change, observation period and final versions. Preserve the pre-repair backup until the system operates normally through several expected cycles.
Prevention
Keep storage healthy, control high-frequency entities, review custom components before Core upgrades, stagger intensive backup and database tasks, monitor free space and resources, and retain logs long enough to capture the minutes before a watchdog event.
Log-rate diagnosis
A component writing thousands of repetitive messages can consume CPU, storage and I/O while hiding the first useful exception. Measure the logger and message that dominates the interval. Correct the component or temporarily raise only that logger’s threshold after preserving evidence. Do not disable all logging, because the next freeze would become harder to diagnose.
State-change diagnosis
Review the busiest entities and whether their update rate changed before the problem. A noisy power sensor, malformed MQTT publisher or template feedback loop can create excessive state and database activity. Correct the measured source, then confirm state-change and Recorder write rates return to normal without losing necessary monitoring.
Health-check interpretation
If the Supervisor watchdog restarts Core, record how long the health check failed and whether API, frontend and automation processing stopped together. A proxy-only outage should not normally require a Core restart. Matching the watchdog time to Core logs helps distinguish a real Core stall from an external access problem.
Post-fix observation window
Observe the installation beyond the longest previous interval between incidents. Include at least one scheduled backup, Recorder purge or other recurring workload that previously overlapped a freeze. A short period of responsiveness immediately after restart is not enough to establish a durable repair.
Safe temporary mitigation
If a nonessential integration is strongly implicated but no fix exists, keeping only that integration disabled can be a reasonable temporary mitigation. Document the lost functions, monitor the upstream issue and retest after a supported update. Do not normalize scheduled whole-system restarts as the permanent solution.