A single point of failure (SPOF) is one component whose failure, on its own, stops a system or service from working. It can be a device such as a firewall or switch, a link such as an internet circuit, a shared resource such as a power feed or building entrance, a provider, a cloud region, or a person who is the only one able to fix something. Finding and deciding what to do about SPOFs is the starting point for any plan to improve reliability.
At a glance
- A SPOF is anything with no working alternative that a critical service depends on.
- SPOFs hide in shared infrastructure: two circuits in one conduit, two servers on one power strip, two vendors on one carrier.
- Removing a SPOF means adding redundancy and a way to switch to it, then testing that switch.
- Not every SPOF is worth removing; the decision depends on what an outage would cost.
- People, passwords and single vendors can be SPOFs as much as hardware.
What problem it solves
Outages often trace back to one thing nobody realized everything else depended on. A single firewall at headquarters, one internet circuit at a branch, a lone domain administrator account, or a carrier that supplies both “diverse” circuits can each take a whole service down. Thinking in terms of SPOFs turns a vague worry about reliability into a list of specific dependencies that can be fixed, accepted or covered with a recovery plan.
It also helps buyers question claims of resilience. Paying for a second circuit or a second server only helps if the two don’t fail together.
How it works
Mapping dependencies. For each critical service, trace everything it needs: user devices, local network, firewalls, internet or WAN links, the carrier network beyond them, data center power and cooling, cloud regions, identity systems, DNS and the people who run them.
Identifying SPOFs. Any element without a working alternative is a single point of failure. Look especially at hidden shared dependencies, such as two circuits leaving a building through the same conduit or two providers reselling the same underlying network.
Removing or reducing them. Typical fixes include a second firewall in a failover pair, a second internet circuit from a different carrier and path, cellular failover as a backup link, SD-WAN to steer traffic across links automatically, redundant power, and secondary cloud regions. For people, it means named individual accounts with least privilege, cross-training, documented recovery procedures, and a separately controlled, audited break-glass credential kept in a privileged-access or password manager.
Testing. Redundancy that has never been tested may not work when needed. Scheduled failover tests confirm that traffic actually moves and that the backup path has enough capacity.
Accepting the rest. Where removing a SPOF costs more than the risk it carries, organizations document it and plan recovery, sometimes with services such as disaster recovery as a service (DRaaS).
When it matters for buyers
- When ordering a second circuit. Ask whether the two are physically separate, from the building entrance to the carrier network. Our internet access overview covers diversity options.
- After an outage. Find out which single component failed and whether anything else depends on it.
- When consolidating vendors. One provider for internet, voice and security simplifies management but can create a single provider dependency.
- When staff or contractors leave. Check who else has the access and knowledge to keep systems running.
Questions to ask vendors
- Where are the single points of failure between our site and your network?
- Do our primary and backup circuits share any building entry, conduit, route or carrier facility?
- Is your backup service delivered over your own network or another carrier’s, and which one?
- What fails over automatically, and how long does it take?
- How often should we test failover, and will you support the test?
- What would a regional outage in your network mean for our sites?
How it differs from high availability (HA)
A SPOF is a weakness; high availability (HA) is the design approach that removes it by adding redundant components and automatic failover so service continues when one part breaks. Eliminating SPOFs in the paths that matter is the core of HA design. The result shows up as uptime, the measured share of time the service actually works. HA is not the same as removing every SPOF: many highly available systems still depend on a shared element, such as one data center or one identity provider, that the design has accepted.