GDS Technology — Built, Wired and Secured podcast banner
Watch on YouTube →
Episodes Built
Episode 161

The Single Point of Failure Audit: Finding the One Component That Can Take Down Your Entire Building

October 20, 2026
Key takeaways
  • Trace the infrastructure serving critical loads from utility feed to end device.
  • Small components such as an isolation valve can disrupt multiple critical spaces.
  • Review maintenance logs for recurring failures and act on observed patterns.
  • Test and maintain backup systems; redundancy on paper is not resilience.
  • Use a current risk register with component, risk, mitigation and an assigned owner.

Show Notes

Why one small component can disrupt an entire building

Modern buildings depend on systems that share power, network paths and operational infrastructure. A failure that once affected one isolated service can now cascade across information technology, building controls and physical security. The episode opens with a hypothetical medical office building whose lights, elevators and computers all fail after one breaker trips. A component’s importance can be easy to overlook until multiple systems depend on it.

Phone systems, data networks and building controls were once more separate. Today, access control, monitoring and even an elevator phone may rely on shared infrastructure. IT, operational technology and physical security can share power and network paths, while older maintenance checklists may miss these cross-system dependencies.

Look beyond the obvious equipment

A chilled-water loop in a medical center served both a data closet and a surgical suite. The loop depended on one original isolation valve. When it failed, cooling stopped, the data closet began heating up, and the surgical suite had to be taken offline. The overlooked valve was not the chiller or pump, but the small component in between.

An audit starts by identifying loads that must keep running: the episode names an emergency room, operating suite or data center in a hospital, and elevators or tenant server rooms in an office building. Trace each relevant path from the utility feed to the end device, documenting switches, breakers, controllers and cables. This does not mean tracing every cable in the building; focus on infrastructure serving critical loads.

Use evidence and scenarios to expose weak links

Look for places with no effective backup, where one component failure leaves nothing to take over. Maintenance records can reveal patterns such as repeated breaker trips or a pump cycling too often. Logs only help when someone reviews them, notices trends and acts. Collecting records without using them is just paperwork.

Pair the records review with “what if” conversations. Work through a failure scenario: what happens if a key route to a wing goes down, who should be contacted, and how long can operations continue? Unclear answers reveal gaps in response ownership, contingency planning or repair expectations.

Redundancy has to work in practice

A generator and an uninterruptible power supply do not guarantee resilience merely because they appear on a drawing or inventory. The episode describes generators that had not been load-tested, dead UPS batteries and a fuel tank that was half full. When power flickered, the backups failed. The building experienced a week of downtime and a tenant lawsuit despite substantial spending on backup equipment.

Testing, maintenance and knowing limitations make redundancy useful. A backup that has not been maintained is simply another component that may fail. Tenants care whether the lights stay on, not what equipment appears on an inventory, and repeated outages can undermine confidence in the building.

Start with one system and record the plan

Choose one critical system, such as an elevator or server-room cooling. Map its path from utility to end device and document the components. Select one failure scenario and walk it through with the team: what happens if a breaker trips, who owns the response and how long would a repair take?

Record findings in a simple risk register with three columns: component, risk and mitigation. Assign an owner to each mitigation and keep the register current. The goal is not to eliminate every risk; it is to know where risks are and have a credible response plan. Explain business impact in terms ownership understands, such as the cost of a day of downtime or losing a tenant after repeated interruptions.

Why dependencies are easy to miss

One challenge is that criticality does not always match appearance. A large chiller is obvious; a small valve between equipment may not be. Yet the smaller part can control whether a shared service remains available. The audit therefore needs to include transitions and connections, not only equipment with a dedicated maintenance schedule or a prominent label.

Mapping also makes conversations across teams more concrete. IT staff may understand the data closet while facilities staff understand the cooling loop, but the dependency between them can fall between responsibilities. Following a service from its source to the point where people rely on it helps teams see where assumptions, ownership and backups intersect.

Make reliability an operating discipline

Reliability comes from disciplined maintenance and disciplined thinking about the whole system. Follow critical paths, review patterns, test backups and make responsibility explicit. The best operational day may be the one no one notices because essential systems simply worked.

The speakers mention a free checklist at gdschechnology.com covering critical-load mapping, path tracing, maintenance-log review and what-if scenarios. Listen to the episode for the full conversation and share it with someone who owns or operates a building.

Deeper dive

Why the smallest component can create the biggest outage

A building-wide disruption does not always begin with dramatic equipment failure. Sometimes it begins with a breaker, valve, controller or connection no one has considered critical. The episode opens with a busy medical office building where lights flicker, elevators stop and computers go dark after one breaker trips. A small component can become a major operational dependency.

Buildings are more interconnected than they were years ago. Phone systems, data networks and building controls once operated more independently. Now, access control, monitoring and even elevator phones may rely on shared infrastructure. IT, operational technology and physical security can share power and network paths. This convergence enables connected operations, but a fault can travel across systems previously treated separately.

Maintenance checklists written for a less interconnected building may miss cross-system dependencies. An audit needs to examine the whole path behind an essential service, not just prominent machines in a mechanical room.

Trace the path behind critical loads

A practical audit starts by asking what absolutely must continue operating. Examples in the episode include a hospital’s emergency room, operating suite and data center, or an office building’s elevators and tenant server rooms. The priority list depends on the building and its operations.

After choosing a critical load, trace its route from the utility feed to the end device. Document each relevant switch, breaker, controller and cable. This does not mean tracing every cable in the building. Follow the infrastructure serving loads whose interruption would matter most. The work may require getting into ceilings and closets, but seeing the route reveals hidden dependencies.

On the map, identify places with no backup or alternate path. If one component fails and nothing takes over, it is a potential single point of failure. It may be obvious, like a main breaker, or easy to overlook, like a valve between major equipment.

Small parts can affect critical services

One story involves a chilled-water loop serving both a data closet and a surgical suite in a medical center. The loop depended on a single isolation valve that was original to the building. When it failed, the cooling loop shut down. The data closet began heating up, and the surgical suite had to be taken offline.

The valve was not a chiller or pump; it was a modest component that had escaped attention. Its replacement cost was described as $200, while the consequences touched critical operations. Risk should be judged by what a component supports, not by how large or expensive it looks.

Use maintenance history, but do not stop there

Maintenance logs can identify weak links before they fail. Repeated breaker trips or a pump cycling too often may signal a developing problem. Records are useful only if someone reviews them, looks for patterns and responds. A checklist signed and filed without analysis does not create resilience.

Logs cannot provide the entire picture. Run “what if” scenarios together. What happens if a key route serving a wing goes down? Who gets called? How long can the building operate before it is in trouble? Uncertain answers reveal planning gaps. The exercise turns system maps into practical decisions about response, ownership and time.

Redundancy is only real when it is tested

Backup equipment can create false confidence. The episode describes buildings with two generators that had not been load-tested in years, dead UPS batteries and a half-full fuel tank. When utility power flickered, neither generators nor UPS provided expected protection. The building went dark, resulting in a week of downtime and a tenant lawsuit.

Redundancy on paper is not resilience in practice. Backup systems need maintenance and testing, and operators need to understand their limitations. An untested generator or dead battery is not dependable protection; it is another potential point of failure.

Tenants judge a building by whether services remain available, not by how much was spent on backup equipment. Repeated interruptions can damage confidence and contribute to a tenant seeking another building. Functional testing is an operational and business concern, not merely an engineering task.

Build a risk register that people will use

For a facilities manager starting on Monday, choose one critical system, such as an elevator or server-room cooling. Map the path from utility to end device, document each component and select a failure scenario to discuss with the team.

Ask practical questions: What happens if this breaker trips? Who is responsible? How long might it take to fix? Write findings in a simple risk register with three columns: component, risk and mitigation. Assign an owner to each mitigation and keep it current. The format need not be elaborate; it needs to guide action.

When requesting resources, frame risk in business terms. Consider the cost of a day of downtime or a tenant moving out after repeated power interruptions. That helps ownership compare preventive work with the cost of an outage. The goal is not to remove all risk, but to understand weak links and plan for failure.

Make the audit repeatable

A map and risk register are most useful when they stay current. Changes to equipment, wiring, controls or operating priorities can alter the path that supports a critical load. When the building or its systems change, review whether the documented route and mitigation still match reality. A stale register can be as misleading as having no register at all.

Keep the review focused enough to complete. The episode suggests starting with one system rather than attempting to document the entire building in one effort. That makes it easier to identify an owner, test one scenario and close specific gaps. The process can then be repeated for other important loads as time and resources allow.

Reliability is a discipline, not a purchase

Buildings need more than an equipment list and a promise of backup. Teams must map dependencies, review maintenance patterns, test alternate systems and know who responds when something goes wrong. Thinking about the whole system reveals small components that could interrupt several services at once.

Start with one critical system, follow its path, challenge backup assumptions and document the mitigation. The speakers point listeners to a free audit checklist at gdschechnology.com. Listen to the full conversation for examples and practical discussion of finding weak links before they dictate the timing of an outage.