Automation Fail-Safes: Plan for the Outage

Section 1: What keeps the house usable when the cloud fails? (Introduction)

A fail-safe automation keeps the house usable when the internet, hub or power fails: local control, manual overrides and a written plan for what stops. Design the failure path before adding another convenience rule, and test it once a season.

The internet goes out at the worst possible time: a storm takes the fiber line, a router update bricks the gateway, or the power blips and nothing comes back cleanly. The lights still have power. The lock still has a battery. The house is fine. The cloud is not.

That distinction is the whole subject of fail-safes. A smart home has two brains: the devices in your house and the services they talk to. When the second one disappears, anything that depends on it stops, and anything that runs locally keeps going. The difference is not luck. It is where the logic lives.

Most homes discover this by accident, at the moment they need the house to work. A lock that will not open, a routine that will not run, a camera that records nothing. The fix is a small amount of design work before the outage, not a purchase after it.

This guide covers what actually stops when the internet drops, what local control means on Matter, Thread, and hubs, how to design manual overrides and power backup, and how to test the whole thing in an afternoon. For the wider automation picture, start with the Automation hub.

Section 2: What stops, and what keeps working?

Start by separating the things that need the internet from the things that do not.

Stops when the internet drops:

• Voice assistants. A phrase is processed in the cloud. With the connection down, the microphone still hears you and nothing happens.
• Cloud routines. A schedule that lives in the Alexa or Google app runs on their servers, not on your hub.
• Remote app control. Unlocking the door from the office requires a path through the vendor’s cloud.
• Push notifications. The camera may record, but the alert cannot reach your phone.
• Cloud video history. Clips upload after the fact; if the upload fails, the history has a gap.

Keeps working:

• Wall switches. The physical switch still cuts power, which is both the oldest automation and the most reliable one.
• Physical keys. Most deadbolt-style smart locks include a key cylinder. Check yours before you need it.
• Local schedules. If the schedule lives on the device or a local hub, it keeps running.
• Local recording. A camera writing to a microSD card or an NVR keeps recording; only the remote view and alerts stop.
• Codes already active on a lock. The lock stores them, so the keypad still works.

That last point is more subtle than it sounds. Schlage’s own support documentation says scheduled codes in its app are stored in the cloud, so they will not work if the lock goes offline; only the codes that were active when the lock lost Wi-Fi continue to function. The lock is not broken. The schedule is in the wrong place.

The lesson is not “avoid the cloud.” Cloud services are why remote access and notifications work at all. The lesson is to know which functions you are willing to lose for an hour, and which ones must keep working.

Section 3: What does local control actually mean?

“Local control” is one of the most abused phrases in the category. It usually means the command travels from your phone to a hub on your own network, without a round trip to a data center. It does not always mean the device works with no internet at all.

Matter and Thread

Matter was designed with local connectivity as a core property. The Connectivity Standards Alliance describes it as “consistent and responsive local connectivity,” and the standard runs over IP, so a Matter device can be controlled on the local network rather than through a vendor cloud.

Thread, the mesh radio underneath many Matter devices, is built the same way. The Thread Group describes a network with “no single point of failure” that can self-heal, which is exactly the property you want in a house full of battery-powered sensors. A Thread border router bridges that mesh to your network; if the router is on battery backup, the mesh keeps working when the internet does not.

Zigbee, Z-Wave, and hubs

Zigbee and Z-Wave devices talk to a local hub, and the hub runs the automation. That is why a Zigbee button can still turn on a Zigbee bulb during an outage, while a cloud routine cannot. The same is true of Home Assistant, which describes itself as open-source home automation that “puts local control and privacy first”: the automations run on your hardware, not someone else’s.

What local does not fix

• Remote access. If you are away, reaching the house still needs a path in, usually the vendor’s cloud or a VPN you set up yourself.
• Voice. The assistant still sends audio to a server.
• Firmware updates. A device that cannot reach the update server stays on its current firmware, which is fine for an hour and not fine for a year.
• Setup. Pairing a new device usually needs the app and the cloud, so do it before the outage, not during.

The practical question is not “is this device local?” but “where does the automation run?” A local bulb controlled by a cloud routine is still a cloud routine. A cloud bulb controlled by a local hub is local until the hub needs the vendor’s API.

Section 4: How do you design the fail-safes?

A fail-safe is a layer that works when the layer above it does not. For a house, three layers cover most of it.

Layer 1: Manual override

Every critical function needs a way to work by hand.

• Locks: a physical key, and a keypad code that is stored on the lock rather than scheduled in the cloud.
• Lights: the wall switch. If a smart bulb is in the fixture, the switch cuts its power; the light still works, but the smart features do not. That is an acceptable trade for a hallway.
• Garage: the wall button and the remotes work without the app. Know where the manual release is, and how to use it if the door is stuck.
• Water shutoff: if you have an automatic valve, find the manual bypass before you need it. A valve that closes on a false alarm and cannot be reopened is its own outage.
• Heating: a smart thermostat with a local schedule keeps running; one that depends on the app does not. Check which yours is.

There is also a design question hidden in the hardware: fail-secure versus fail-safe. A lock that loses power stays locked, which is secure but means the key is now the only way in. A valve that loses power may close, which protects the floor but shuts off the water. Neither is wrong. Decide which failure you can live with, and make sure the manual override matches.

Layer 2: Local logic for anything that must run

Move the automations that matter off the cloud and onto a hub or the device itself:

• A schedule that turns the porch light on at sunset can live on a local hub.
• A leak sensor that closes a valve should be a local rule, not a cloud scene.
• A thermostat setback can live on the thermostat.
• A camera that records continuously should write to a card or an NVR, not only to a plan.

The voice routine is the right tool for “I want this now.” The local rule is the right tool for “this must happen whether or not anyone is home, and whether or not the internet is up.”

Layer 3: Power and connectivity

A local network still needs power. A small UPS on the router, modem, and hub keeps the LAN alive through a short outage, which is enough for local control, local recording, and local schedules. It does not restore the internet if the line itself is down, and it does not run the furnace.

For life-safety systems, cellular backup is the standard answer: a monitored alarm with a cellular radio can still call out when the broadband is gone. For everything else, a phone hotspot is a manual fallback, not an automation.

Finally, make the outage visible. Most apps show a device as offline, but nobody checks. A local hub can send a notification when a device stops responding, and a simple weekly glance at the device list catches the ones that quietly dropped. Securing your smart home network covers the monitoring side.

Section 5: How do you run the drill?

You do not know what works until you test it. The drill takes an hour and costs nothing.

1. Unplug the internet, not the router. Pull the WAN cable from the router, or disable the uplink, so the local network stays up and the internet does not. If your router and modem are one box, unplug the coax or fiber and leave the LAN running.
2. Walk the house. Try the things that matter: unlock the front door with the keypad and the key, turn on lights at the wall, check the thermostat schedule, open the garage with the wall button, confirm the camera is still recording to its card, and check whether the leak valve can be operated by hand.
3. Check what the app says. Remote control should fail; local control may still work if the app can reach the hub over the LAN. Note which is which.
4. Restore the connection and compare. Anything that failed in a way you did not expect is a gap.
5. Fix one gap at a time. Add a key, move a schedule to the hub, put the router on a UPS, or replace the one device that cannot work locally.

Do it twice a year, and tell the household what you are doing so nobody panics when the internet “goes out.” Do not disable smoke alarms, CO alarms, or a monitored security system for the test; those are life-safety devices with their own backup paths, and they should stay armed.

Section 6: What is the three-layer plan? (Conclusion)

1. Give every critical function a manual override. A key for the lock, a switch for the light, a handle for the garage, a bypass for the valve. If you cannot operate it by hand, you do not control it.
2. Move the must-run automations to local logic. Schedules, leak responses, and security rules belong on a hub or the device, not in a cloud app. Keep voice for the things you start on purpose.
3. Back up the power and watch the devices. A UPS on the router, modem, and hub buys hours of local control. A weekly look at the device list catches the failures before they matter.

Some homes can skip most of this. If you have two smart plugs and a bulb, the wall switch is your fail-safe and it already works. If you rent and cannot change the router, your options are limited to keys, switches, and local device schedules. And if a function is life-safety — smoke, CO, medical — it should not depend on your automation at all.

The goal is not a house that never goes offline. It is a house that keeps working when it does, and tells you what happened afterward. Design the layers, run the drill once, and the outage becomes an inconvenience instead of a crisis.

Where to buy

Related reading

• Voice Assistant Routines 101 — the routines you start on purpose, and what they need.
• Smart Home Network Security 101 — the network those fail-safes run on.
• Smart Locks 101 — keys, codes, and what happens when the battery dies.
• Best Smart Garage Door Openers — which controllers keep a local path when the cloud drops.

Sources

• Build With Matter — Connectivity Standards Alliance, local connectivity as a Matter property, checked October 2026
• Thread Benefits — Thread Group, mesh networking and no single point of failure, checked October 2026
• Home Assistant — Open Home Foundation, local control and privacy positioning, checked October 2026
• Will Scheduled Codes in the Schlage Home App Work if the Lock Goes Offline? — Schlage, cloud-stored schedules versus codes already on the lock, checked October 2026