YesโHome Assistant can keep local devices and automations working during a temporary internet outage, but only where the complete control path stays inside the home network.
The server process, a local dashboard, and Zigbee or other local devices may continue while cloud integrations, remote URLs, voice services, external notifications, or vendor APIs stop. Build a path map for critical functions, perform a short planned WAN test while local networking remains powered, and classify each result before changing hardware or firewall rules.
Map the Complete Path for Each Critical Action
For each essential action, record the client URL, DNS resolver, authentication path, Home Assistant host, automation trigger, device integration, message broker, and any external API. A local-looking dashboard card may still call a cloud service, while an automation can remain local even if remote access is unavailable.
A fully local device-control path is possible only when the selected devices and integrations do not require their vendor cloud.
Mark each path local, hybrid, cloud-only, or unknown. Test unknown paths first in a noncritical room, and keep a manual control method for locks, alarms, heating, and other functions whose failure has real consequences.
Run a Bounded WAN-Outage Test
During a planned window, disable only the WAN uplink while leaving the router, switches, access points, DNS server, Home Assistant host, and local devices powered. Use the local URL from a device already on the LAN and record dashboard access, event-to-action response, and integration state.
During WAN loss, local protocols can continue while cloud-dependent functions cannot. Use the distinction as a test hypothesis and verify every device path in the actual home.
If Home Assistant itself is unreachable locally, test local DNS and the direct address before blaming the application. If the dashboard works but one device fails, classify that integration's path. If automations fail broadly, inspect shared DNS, broker, time, or storage dependencies.
Repair Local Access and Dependency Gaps
Configure a stable local URL and resolver path that does not require public DNS during a WAN outage. Prefer local device integrations where they are reliable, keep essential automations free of mandatory external APIs, and define fallback values or skip behavior for optional weather, voice, and notification calls.
The architectural boundary in the local-control outage model helps identify which dependency must move inside the network rather than merely adding server resources.
Do not replace every cloud device after one failure. First verify whether the unavailable path is the device service, the client using a remote URL, or a local resolver that incorrectly forwards all names upstream.
Retest and Define the Outage Boundary
Repeat the same WAN test after changes and run the critical actions from at least two local clients. Keep the outage long enough to cross one scheduled automation and one device reconnect, then restore WAN and confirm cloud integrations recover without manual repair.
A pass means the documented local functions work at acceptable latency, manual fallbacks exist for exceptions, and internet-dependent failures are visible rather than silently producing unsafe actions. Remote access is expected to fail unless an independent path exists.
Stop when the outage matrix matches the household requirement. Escalate when a supposedly local integration still contacts an external endpoint, local DNS fails with the WAN down, or reconnect creates duplicate commands; preserve timestamps and packet or log evidence for the responsible component.
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.

