Cloud dependency disables devices when the internet drops
Aliases: cloud-tethered devices · WAN single point of failure
What it is
Many smart devices put the control plane in the cloud: commands leave the phone, travel to the vendor's servers, and come back to the device in the living room. That produces a counterintuitive failure mode — the wide-area network drops (home Wi-Fi perfectly fine), the phone and the device sit in the same room, and control is dead: the command must detour through a server outside the house, and that road is closed. Device intact, local network intact, function paralysed.
This is not the router failing — that is the home network's own problem. Cloud dependency is the narrower case: technically fully reachable locally, architecturally chosen not to be. A distant cloud becomes the single point that local devices hang from.
Why it happens
Vendors have solid engineering and commercial reasons for the cloud path: NAT traversal makes remote access zero-configuration, a unified account system powers assistant integrations, compute and firmware updates live server-side, and usage data aggregates for analysis. These benefits pull the control plane naturally toward the cloud.
The cost is that the control chain acquires serial links outside the front door: ISP failures, modem failures, vendor cloud outages, regional datacentre incidents — any one link dropping paralyses local function. A serial dependency's reliability is the product of its links, and users can neither see nor intervene in these links. The sharpest form is a vendor-side outage: everything at home is fine, the whole fleet of devices goes limp, and the only remedy is to wait for a server thousands of kilometres away — the user's sole available action is refreshing a status page.
Distinguishing two failure domains is the precondition for diagnosis: is the LAN down (Wi-Fi, router) or the WAN (fibre, ISP, cloud)? If the LAN is down, everything is down, fairly enough. When the WAN is down, the local network still runs and direct local control is entirely feasible — the loss of function is purely an architectural decision. That distinction is also the acid test when buying: unplug the modem and see what still answers. It exposes the device's architecture on the spot.
Studying it
- Outage event analysis: public incidents at large cloud providers and device vendors offer natural experiments — which functions survived and which died during an outage can be archived directly from incident reports and user reports. No deployment needed, and the samples are real.
- Architecture inventories: classify retail devices as cloud-required / cloud-optional / local-only, with indicators such as whether commands must transit vendor servers, the functional inventory under WAN loss, and whether third-party local gateways can drive the device. The inventory doubles as an industry baseline.
- Local-first argumentation: the local-first software movement (Kleppmann et al., 2019) argues systematically for "local as the source, network as the enhancement" at the application level — software can architecturally avoid depending on a persistent connection while keeping every core function. The argument maps directly onto device control planes.
One methodological caution: vendor claims of "local control" often fail measurement (local wake-up but cloud authentication; local commands but cloud state). Verify by unplugging the wire, not by believing the spec page's wording.
Where it stops holding
- Local execution is not local completeness. Most devices "supporting local control" still need the cloud for first-time pairing, voice skill binding or remote management; enrolling a new device during an outage is often impossible. Classify claimed-local devices by "what works with the WAN cut", not by marketing language.
- Purely local has real costs. Remote access, cross-site linkage (monitoring the holiday cabin), cross-vendor scene integration inherently need relay services; going fully cloud-free gives those up. "Cloud dependency is harmful" holds for core functions, not for value-added ones.
- Voice assistants are inherently cloud-dependent. Wake-word detection is local; language understanding has mostly lived in the cloud — the offline survivability of voice control depends on the semantics chain's architecture, which the lamp or switch cannot decide alone.
Applying it
- At selection time, distinguish cloud-optional from cloud-required protocols: open local protocols (device radios driven through a local gateway, LAN-direct standards) beat devices with pure cloud APIs.
- Require core functions — lighting, locks, thermostats — to stay locally controllable without the WAN; write it into procurement and acceptance criteria.
- Keep a local direct path inside the home network (local name resolution, LAN discovery) so the route never needlessly circles the globe.
- How to check: unplug the modem (router stays on) and test each device for control, automation and history — alive or dead — producing a per-device outage function list. Any core device whose control dies on that list is a cloud-dependency defect.