What still runs in Home Assistant when the internet drops?

Zigbee lights, Z-Wave switches, ESPHome and local Tasmota devices, and any automation that only talks to those stay up. Nabu Casa, Alexa, Google Assistant, cloud plugs, and phone alerts to someone who is not on your Wi-Fi stop. The Home Assistant box itself does not need the internet. The integrations you forgot were cloud do.

That split is the whole outage. Power is on, the router is on, the WAN link is dead. The dashboard on a tablet in the house still loads if you open the local address. A button press that toggles a bulb still toggles the bulb. The part that feels like “the smart home is down” is almost always a notification, a voice speaker, or a device that was never local in the first place.

What keeps working on the LAN

Home Assistant Core keeps running automations, scripts, helpers, and the recorder. SQLite on the Pi, or MariaDB on the mini PC, does not phone home to write a state change. The dashboard is a page served by that box. A browser on the same network, pointed at the IP or at homeassistant.local, still gets it. mDNS does not need Cloudflare, and it does not need your ISP’s resolver.

Zigbee is the clearest win. ZHA and Zigbee2MQTT talk to a coordinator on USB or to an SLZB on Ethernet. The mesh is radios in your walls, not a session to a vendor. A button, a motion sensor, a bulb, a group: if the automation’s action is “turn on that light entity,” the internet is irrelevant. Z-Wave JS is the same shape with a different stick. The stick has to be plugged into the machine that is still powered. A coordinator that lives on a second Pi is fine, as long as that Pi is on the LAN and not on the far side of the dead WAN.

ESPHome’s native API is a local connection from Home Assistant to the plug. Tasmota is local if it is publishing to a Mosquitto broker you run yourself, and it is not local if the only path is a cloud MQTT or the vendor app. Shelly devices on current firmware can be driven over the LAN with their RPC API. They can also be left in a mode that wants Shelly’s cloud. The hardware does not tell you which one you configured. The outage will.

Frigate on the same network keeps detecting and recording if the cameras are RTSP on the LAN and not a cloud doorbell. Piper and Whisper keep doing voice if the models are already downloaded. Matter and Thread devices that were commissioned to Home Assistant keep talking to a border router that is in the house. Thread does not route through your ISP. A border router that is an Apple TV or a Home Assistant Connect ZBT-1 sitting on the LAN is still a border router when the fiber is cut.

What looks local and is not

The companion app on a phone is the usual lie. On the house Wi-Fi, with a local URL filled in, the app can hold a websocket to Home Assistant and show the dashboard. Step outside, or let the phone fall onto cellular, and that websocket has nowhere to go. There is no internet path into the house. Nabu Casa was that path. A Cloudflare Tunnel was that path. Tailscale was that path, and Tailscale’s coordination and DERP relays are also on the internet, so a phone on cellular often cannot build a new tunnel to a home node that itself has no WAN. Anything already connected may limp. Do not count on it.

Push notifications are a second cloud, even when the automation is local. The mobile_app notify service hands the alert to Firebase or APNs. Those servers are not in your closet. Local push only helps while the app is already connected on the LAN. A notification that means “the washing machine finished” dies in an outage if the person who cares is at work. The automation trace will say the notify call failed or timed out. The light action above it in the same script will have succeeded. Read the trace before you decide the house is broken.

Voice is the other half-failure. An automation that turns on the hall light and then speaks through Nabu Casa Cloud TTS, or through a Google speaker, or through Alexa, will do the light and skip the sentence. People hear silence and flip the dumb switch, then tell you Home Assistant died. The bulb entity changed. The speaker is a cloud client that caches almost nothing useful. HomeKit is kinder than those two: an Apple TV or HomePod on the same LAN can still reach a HomeKit bridge running in Home Assistant. Controlling the house from a phone that is away, through iCloud, cannot. Same app, two paths, only one of them survives.

Cloud-only devices are worse than a missing notification, because the entity goes dead and the automation was the light. Tuya Wi-Fi plugs that report through Tuya’s cloud, older Kasa or Meross accounts that were never flashed, SwitchBot via the cloud API, and any camera that only exists inside a vendor app: the wall still has power and the device still has Wi-Fi. Home Assistant cannot see it, because the integration was a poll of someone else’s servers. A Zigbee version of the same plug would have toggled. The Wi-Fi version did not. That is a purchasing decision you already made, revealed by an excavator two streets over.

The automation that half-fires

Look at the actions, not the trigger. A Zigbee motion sensor is a fine trigger during an outage. The damage is in the sequence after it. I keep finding the same script: turn on a local light, wait, set a thermostat that is actually an ecobee cloud entity, then notify the phone. The light happens. The thermostat call errors. The notify call errors. If the script is set to abort on error, the light might happen and the rest never runs, which is fine. If a later action was the one that mattered, you built a local trigger in front of a cloud effect and called it a local smart home.

Weather, electricity price, calendar, and presence-from-a-cloud-ping are the conditions that stall this. A “if the Met.no temperature is below zero, turn on the pipe heater” automation does not know the temperature when the API cannot be reached. The sensor goes unavailable or sits on a stale value, depending on the integration. Stale is more dangerous than unavailable. Unavailable fails the condition. Stale happily turns the heater on in June because the last successful poll was a cold morning and you have not looked at the entity in nine hours. For an outage that lasts an afternoon, treat cloud sensors as untrusted. For a number that protects a pipe, use a local probe.

DNS is the boring failure that makes the dashboard “gone” while the server is fine. The bookmark is a Nabu Casa hostname, or a name that only resolves through a tunnel. The phone asks the ISP router, the router asks a resolver on the internet, the internet is the thing that is down, and the bookmark fails. The server is at 192.168.1.20 the entire time. Type the IP once, on the tablet that stays home, and leave that bookmark named like it is the outage URL. Internal and external URLs in the companion app exist for this. The external one will not save you when the external path is the outage.

Who should not trust this

None of the above applies if Home Assistant itself is a container on a VPS. The house then reaches the brain over the internet, and the outage is the product. It also does not apply to a household whose only switches are voice assistants. The lights may be Zigbee and still be unusable if nobody in the house will open a dashboard or press a wall button. A wall switch that cuts mains to a smart bulb is a different disaster. A wall switch that is itself Zigbee, or a dumb switch left in the circuit, is the offline interface.

Timers you already started keep running. A delay in an automation, a schedule helper, and a timer that was counting down before the WAN died do not ask the internet for permission to finish. What they cannot do is fetch a new version of the calendar they were built from. If the evening routine is a local time trigger, it fires. If it is “when the Google calendar event starts,” the trigger is the outage.

Do not confuse this with a power cut. A UPS on the Home Assistant box and the router keeps the brain and the Wi-Fi up for a while. It does not keep a bulb alive if the bulb is on the other circuit and the room is dark. Internet-down is the kinder test, and it is the one worth running on purpose. Unplug the WAN cable for ten minutes on a weeknight. Press the button that is supposed to do the lights. Watch the phone of the person who is not home. Open one cloud plug. That is the inventory. The list you write down is the list of things that are allowed to depend on a company, and it is usually longer than the list you would have sworn to.