A county public safety department just asked its residents to sign up for a new emergency alert system. Text, email, voice, mobile app. Scan the QR code, you're covered.

Every one of those channels requires the same thing: the cell network and the internet both staying up. The department is asking residents to adopt a disaster notification plan that fails under the exact conditions a disaster is most likely to create.

This is Pillar Two, Signal vs. Noise, and Pillar Four, Operational Reality, in one case. The noise here isn't misinformation. It's a well-intentioned system that looks like preparedness and functions like a single point of failure.

Look at what actually got adopted. The county's new notification platform is a third-party SaaS product. That means the county's emergency communication capability now depends on three things staying operational at once: the cell or internet network, the vendor's servers, and the vendor's continued contract with the county. Any one of those breaks and the "new way of sending important notifications" sends nothing.

This is not a hypothetical stack of failure points. It's the standard shape of most modern emergency notification procurement. A department evaluates vendors on delivery speed, channel coverage, and interface polish. Text, email, voice, mobile app all check the box marked "redundant." But redundancy across channels is not the same as redundancy across infrastructure layers. Four delivery methods that all ride on the same internet connection are one failure, not four.

Compare that to what a different community, a few counties over, has been quietly building for over a year. A volunteer-run mesh radio network, no cell towers, no internet, no vendor. Messages hop node to node across the region on unlicensed radio, relayed by devices individual residents bought and set up themselves. It cost each participant about $50 in hardware. There is no subscription to lapse, no vendor to go dark, no server region to fail over. During a regional outage, one of these systems keeps functioning. The other goes dark at the exact moment it's needed.

Neither system is wrong to build. The mesh network isn't a replacement for official alerts and won't broadcast emergency-management updates on its own. It also has real limits. Coverage depends on node density and terrain, and there is no guarantee a given household sits within range. But the gap between what county leadership adopted and what would actually survive the failure mode it's meant to solve is the story. Nobody asked the second question. They asked "can we notify people faster" and stopped. They didn't ask "what happens when the layer under all of this is the thing that fails."

This is worth naming plainly because it is not unique to one county. Most enterprise crisis communication platforms, the ones boards approve budget for every renewal cycle, are built the same way. Cloud-hosted, internet-dependent, vendor-operated. The pitch deck says multi-channel redundancy. The architecture says single point of failure with a good interface.

Two takeaways, and they apply as much to a corporate board evaluating a vendor communication platform as to a county government evaluating a resident alert system.

First, redundancy plans get evaluated against the wrong failure category. A vendor SaaS notification tool answers "what if we need to reach people quickly." It does not answer "what if the internet and cell network are both down when we need to reach people," which is a more common condition during a regional disaster than most procurement processes account for.

Second, adopting a new system is not the same as closing the gap. It can look like progress on paper, new vendor, new QR code, positive press, while leaving the actual operational risk untouched. The distinction only shows up when someone asks what specific failure mode the new system is meant to survive, and checks that against what it actually depends on.

Third, this is a due diligence question, not a technology question. Nobody on the procurement or board side needs to understand LoRa radio or flood routing protocols. They need to ask the vendor one plain question before signing: name every piece of infrastructure this system needs in order to function, and tell us which of those pieces is most likely to fail during the event this system is meant to help us survive. Vendors rarely volunteer that list. It has to be asked for directly, and the answer has to be checked, not just collected.

Before your organization signs the next vendor contract for emergency or crisis communication, ask one question: what does this system depend on to function, and does that dependency list include anything that's also likely to fail during the exact event this system exists for?