Show Notes
When the Lights Stay On but the Network Goes Down
A hospital can look fully operational during a power-related IT outage. The lights may remain on, yet the systems that depend on the network can fail: electronic health records can freeze, nurse call systems can go quiet, and building automation supporting operating-room ventilation can stop responding. That is the scenario explored in this episode.
The central lesson is that network uptime is not solely an IT issue or solely a facilities issue. It depends on a connected power path: electrical panels, UPS systems, generators, transfer switches, network equipment, servers, applications, and the people responsible for each part. When teams do not understand and test those dependencies together, a routine maintenance event can become a serious operational failure.
The Failure Was Not Exotic
The hospital’s outage began around a scheduled generator test. The facilities team rescheduled the test without informing IT. When the generator did not pick up the load, the UPS provided temporary power for roughly 15 minutes before it was depleted. Critical network-dependent systems then stopped functioning.
The episode makes an important distinction: this was not presented as an unusual engineering defect. It was a coordination failure. A UPS is intended to bridge the gap between a utility-power failure and generator operation. But a UPS cannot create resilience on its own if the generator, transfer process, connected load, and operational communication have not been verified.
- A charged UPS is not proof that the full backup-power chain will work.
- A fueled generator is not proof it will pick up the intended critical load.
- A maintenance schedule does not protect operations when affected stakeholders are not included.
- Reliable systems require tested handoffs, not assumptions.
Why Construction-to-Operations Handoffs Create Risk
The discussion identifies the transition from construction to ongoing operations as a high-risk period. Construction teams are focused on completing a project and turning it over. Operations teams inherit the responsibility to maintain it months and years later. IT may not be adequately included in the handoff at all.
That gap can leave organizations with incomplete or inaccurate information. As-built drawings may already be outdated. Wiring records may not reflect what was actually installed. Panel schedules can be wrong. A building may appear complete while its teams lack a shared, usable understanding of how critical technology is powered and protected.
This is not framed as a question of one team being incompetent. Instead, each group can be highly capable within its own area while still missing the dependencies outside its normal scope. IT may assume facilities has power resilience handled. Facilities may assume IT has independent backup plans. The risk remains unowned between those assumptions until a real event exposes it.
Ownership and Language Both Matter
The episode raises a direct question: who owns the dependency between physical power infrastructure and critical IT systems? Facilities may own the generator and UPS. IT may own servers, switches, and network availability. Property management may have a broader operational interest. Yet the dependency itself may not belong to a clearly accountable owner.
Two complementary issues emerge. One is structural: if no one is accountable for the overall outcome, communication alone may not lead to action. The other is linguistic: IT and facilities often use different terms and measures. IT may discuss uptime and latency, while facilities may discuss breaker coordination and load shedding. Without a shared language, teams can struggle to identify the same problem, much less resolve it.
The practical answer is not to choose between accountability and communication. Organizations need both: a defined owner for critical power-and-technology dependencies and a working process that brings IT and facilities into the same conversation.
Three Practical Steps to Reduce Outage Risk
1. Complete a documented power audit
A real power audit goes beyond a quick walkthrough. It documents what is on each panel, the actual load, and which loads are critical. It should be repeated annually because tenants, equipment, and electrical loads change over time. Preventive maintenance is more effective than discovering missing information during an emergency.
2. Test the handoff under realistic conditions
Teams should test the transfer switch and simulate a real outage rather than assuming the UPS and generator will operate correctly together. Joint load-testing scenarios should include both IT and facilities. Regular testing can reveal problems before they become outages, shifting the organization from reactive response to proactive reliability management.
3. Build a power dependency map
A power dependency map documents every critical piece of IT equipment, the panel serving it, the UPS protecting it, and the backup-power path behind it. It should answer practical questions: If this panel is lost, which switches fail? Which servers are affected? Which applications or building systems stop responding?
- Identify critical network, server, and application equipment.
- Record the electrical panel supplying each device.
- Document the connected UPS and its role in the power path.
- Identify the generator and transfer path supporting that load.
- Show the operational impact if a panel, UPS, or upstream power source is lost.
- Keep the map shared and current across IT and facilities.
Start Before the Documentation Is Perfect
The episode closes with a practical message: do not wait for a perfect audit or a perfect dependency map. Start with what is known. Begin documenting critical systems. Schedule a meeting to establish a joint testing protocol. Improve the process in stages.
The cost of inaction is downtime. In a hospital environment, that downtime can affect systems connected to care and safety. In any commercial building, the same underlying lesson applies: technology reliability depends on disciplined maintenance and coordination between the physical and digital layers of the property.
The next time you are in a building, ask one question: what happens if the power goes down? Then work with the right teams to find out before an outage provides the answer.
Why a Hospital Network Outage Is Often a Building Operations Problem
When people picture a power outage in a hospital, they often picture dark rooms, emergency lighting, and generators starting in the background. But some of the most consequential failures are less visible. The lights can remain on while electronic health records freeze, nurse call systems go quiet, and building automation supporting operating-room ventilation stops responding.
That was the scenario examined in a recent Built, Wired & Secured conversation about the connection between electrical infrastructure and network uptime. The lesson was straightforward: critical technology is only as resilient as the power path behind it and the coordination between the people responsible for that path.
In the episode’s hospital example, a routine generator test was rescheduled by the facilities team without notifying IT. When the generator failed to pick up the load, the UPS carried the affected equipment for approximately 15 minutes and then ran out. The result was a network failure with operational consequences far beyond a single equipment room.
The root cause was not described as a rare engineering mystery. It was a breakdown in coordination, accountability, documentation, and testing.
A UPS Is a Bridge, Not a Complete Strategy
Many organizations take comfort in knowing their critical equipment is connected to a UPS. That is useful, but it can also create false confidence. A UPS is designed to provide temporary power during the transition from a utility-power failure to generator operation. It is a bridge between two power states, not a substitute for a verified backup-power process.
For that bridge to work as intended, several things must be true at once. The UPS must be appropriately connected and charged. The generator must start. The transfer equipment must operate. The generator must pick up the intended load. The connected systems must be correctly identified as critical. And the teams responsible for those systems must know when testing or maintenance could affect them.
If any one of those assumptions is wrong, the organization may discover that its resilience plan was based on hope rather than evidence. As the episode emphasizes, hope is not a strategy.
The Dependency Between Power and IT Can Fall Through the Cracks
This risk often lives between departments. Facilities may own generators, electrical panels, UPS equipment, and maintenance schedules. IT may own servers, switches, applications, and network availability. Property management may have responsibility for building operations and tenant impact.
But who owns the dependency between a specific electrical panel and the network switch it supports? Who confirms that a generator test will not disrupt a critical application? Who makes sure an updated panel schedule is available to the people responsible for uptime?
Without a formal answer, the dependency can remain unmanaged. IT may assume facilities has adequate power protection in place. Facilities may assume IT has designed its own redundancy. Both teams can be acting in good faith while neither owns the end-to-end outcome.
That is why the episode’s discussion of ownership matters. Communication is essential, but conversation without accountability can become a series of good intentions. A resilient organization assigns responsibility for validating critical dependencies and ensures the responsible people have a repeatable process to follow.
Different Technical Languages Create Operational Blind Spots
There is also a language gap. IT teams tend to discuss uptime, applications, latency, servers, and network paths. Facilities teams may discuss breaker coordination, generator capacity, load shedding, transfer switches, and panel schedules. Both sets of terms describe the same operational environment from different angles, but the teams may not naturally connect them.
That difference can make a problem difficult to see. A facilities discussion about a generator test may not immediately communicate which network services could be interrupted. An IT discussion about critical applications may not identify the electrical circuits or backup-power routes they require.
The answer is to create a shared operating language around critical loads. Teams do not need to become experts in one another’s disciplines. They do need shared documents, joint exercises, and clear questions that connect the physical infrastructure to the systems the business depends on.
The Construction Handoff Is a Reliability Test
One of the most important points from the conversation is that failures often begin at the handoff between construction and operations. Construction teams are measured on completing a project. Operations teams are responsible for maintaining what remains. IT may be left out of the transition entirely.
That can produce an avoidable documentation gap. As-built drawings may be outdated by the time they are handed over. Wiring details may not match reality. Panel schedules may be inaccurate. The building can be new, the equipment can be modern, and the operational knowledge can still be incomplete.
For owners and operators, this handoff should be treated as more than a closeout requirement. It is a reliability test. Before a project is considered operationally complete, the teams that will maintain the building and its technology should be able to answer basic questions about critical power paths, connected systems, backup sources, and testing procedures.
Build a Power Dependency Map
The episode identifies the power dependency map as one of the most valuable documents an organization can create. It is a practical record of how critical technology depends on electrical infrastructure.
At a minimum, a useful map should show each critical piece of IT equipment, the panel it is connected to, the UPS protecting it, and the backup-power path behind it. It should also show the consequences of losing a given panel, UPS, or upstream source.
For example, a dependency map should make it possible to identify which network switches, servers, applications, and building systems are affected if a particular panel is lost. That turns a vague outage scenario into a documented operational decision tool.
- List critical IT equipment and the services it supports.
- Document the panel supplying each device.
- Identify the UPS associated with each critical load.
- Record the generator and transfer path supporting the UPS or panel.
- Describe the systems that would be affected by failure at each point.
- Keep the map accessible to both IT and facilities teams.
The value is not in producing a perfect diagram on day one. The value is in making hidden dependencies visible, then improving the documentation over time.
Audit and Test the Entire Handoff
Documentation alone is not enough. The power path needs to be tested. A real power audit should identify what is on each panel, the actual load, and the systems that qualify as critical. It should be repeated yearly because equipment changes, tenants move, loads grow, and infrastructure evolves.
Testing should also go beyond checking that a UPS has charge or that a generator has fuel. Organizations need to test the transfer switch, simulate realistic outage conditions, and confirm that the generator can pick up the required load. Most importantly, IT and facilities should participate together.
Joint load testing is not glamorous, but it creates the information that matters most: what actually happens when normal power is removed. The episode points to regular testing as the difference between finding an issue in a controlled scenario and discovering it during a real outage.
Progress Beats Waiting for Perfection
For many building owners and operators, the hardest part is starting. Existing documentation may be incomplete. Teams may not have a formal joint-testing protocol. The power dependency map may not exist.
The practical advice is to begin with what is known. Identify the most critical systems. Start mapping their panel, UPS, and generator relationships. Bring IT and facilities together to establish a testing process. Improve the records as equipment and knowledge change.
Downtime is the price of inaction. In a hospital, its impact can extend to systems connected to patient care and safety. In commercial properties more broadly, it can interrupt the technology that supports business operations, building services, and occupant experience.
Listen to Built, Wired & Secured for the full conversation and a closer look at how disciplined maintenance, shared documentation, and cross-team coordination can protect uptime before a routine event becomes a critical failure.