The Off-Season Blind Spot: When Building Systems Are Only Tested When They're Needed

Why routine tests can create false confidence

A generator that starts every month may still fail when a real outage arrives. In the episode’s opening scenario, a July heatwave strains the grid, power drops, and a generator that routinely starts stumbles under real load and heat. The point is not that routine inspections have no value. They verify basic functionality and help meet codes and standards. The problem comes when a passing checklist is treated as proof that a building can withstand the conditions of an emergency.

As the discussion explains, a typical test may confirm that a generator starts and runs for 30 minutes, often with no load or only a minimal load. That does not demonstrate that it can power the whole building through a demanding event. The more useful question for property and facilities teams is: what breaks if this system goes down?

Conditions that ordinary tests may miss

• Load: A generator or backup system may behave differently when it must support the actual building load rather than run lightly.
• Temperature: During a hot-weather outage, lost HVAC can raise temperatures in mechanical rooms. Equipment may face an environment unlike the one present during a routine test.
• Power quality: Grid events can involve voltage sags, surges, or frequency variations. A test beginning with clean, stable utility power may not reveal how backup systems handle those conditions.
• Vibration and movement: Full-load generator operation creates vibration that can stress pipes and connections. A lightly loaded test may not expose loosened or failing components.

These factors interact. A system may pass a basic start-up check yet encounter a weakness only when operating under the combination of real load, environmental stress, and disruption.

A failure that passed inspection

One example involved a tenant operating a data-heavy business with a UPS and generator. Both passed their routine tests. During a regional summer power outage, the UPS carried the load for about 15 minutes while the generator ramped up. The generator started but repeatedly tripped a breaker. The cause was a corroded connection that arced and failed under full-load vibration. The tenant lost power for nearly an hour.

A routine test might have identified a dead battery or bad fuel pump, but this particular fault remained hidden because the system was not under enough stress to expose it. The story illustrates the difference between confirming that a system runs and testing whether it performs under the conditions that matter to the business.

Start with what is critical

Facilities teams cannot realistically simulate every disaster. The episode recommends beginning with consequences: identify which system failures would stop the business or put people in danger. The answers depend on the building. A hospital may prioritize life-support and surgical equipment; an office building might focus on elevators and HVAC; a data center will prioritize IT infrastructure.

Once critical systems are identified, teams can design tests to challenge them more meaningfully. This does not require doing everything at once. Incremental load testing is one practical approach: increase load in steps, such as 25%, 50%, and 75%, and observe performance. This can reveal more than simply starting a generator and letting it run.

Use seasons and targeted scenarios

Timing is part of realistic testing. A program that tests only in spring may never show how equipment behaves in extreme heat or cold. Scheduling tests around the seasons when systems are most likely to be pushed can help teams understand how environmental conditions affect performance.

Teams can also use smaller, targeted tests rather than conducting a full disaster drill every month. The examples discussed include focusing one quarter on generator operation under load and another on testing the fire alarm system during a simulated power outage. The priority is to be intentional, learn from each test, and make the exercise relevant to the system’s real role.

Make the business case

Testing costs should be weighed against the consequences of failure. The guests note that an hour of downtime for a critical tenant can cost thousands or tens of thousands of dollars, before considering reputational damage. A few hours of testing may be modest compared with the impact of a real outage. Asking leadership “What breaks if this goes down?” can make the operational risk concrete.

Tenants experience the consequences directly when power flickers or elevators stop. They are less concerned with a passed test report than with business interruption. More rigorous testing therefore serves both building operators and tenants.

Three steps to take next

• Review what current tests prove. Look at the pass/fail criteria and ask what you actually know when a system passes.
• Identify the highest-risk failure scenarios. Determine which outages or system failures would cause the greatest harm to people or operations.
• Create a practical plan to close the gap. Add more realistic conditions to testing incrementally, without assuming the program must be expensive or complicated.

After any real event, debrief—even if the failure was minor. As the episode emphasizes, an unexpected problem is information about the system that the team did not previously have. Use it to improve future testing. The goal is not to run more tests for their own sake; it is to build justified confidence in what the building can handle. Resilience is proven under stress, not in a routine test.

Passing a test is not the same as proving resilience

Imagine a July heatwave, a strained electrical grid, and a sudden power loss. The backup generator has started every month during routine testing, so the building team expects it to take over. But under real load and real heat, the generator falters. The system passed its tests, yet the building is left without the power it needs.

This scenario opens a discussion about an operational blind spot: routine testing often confirms that equipment can perform under controlled conditions, while emergencies expose it to combinations of load, temperature, power disruption, and vibration that those tests may not reproduce.

Inspections and scheduled tests matter. Codes and standards require certain equipment to be tested at specific intervals, and those procedures verify basic functionality. But the episode cautions against treating a pass/fail report as proof of real-world readiness. A generator that starts and runs for 30 minutes—often with no load or minimal load—has not necessarily demonstrated that it can support the building during an outage.

What routine testing may leave out

Real events place systems in conditions that are different from a calm, controlled test. Load is one obvious difference: equipment may have to support far more than it does during a basic run test. Temperature is another. If an outage happens during extreme heat and HVAC is unavailable, temperatures in a mechanical room can rise. The equipment may face conditions unlike those present during an ordinary inspection.

Power quality can also change during a grid event. Voltage sags, surges, and frequency variations may challenge backup systems. A routine test that begins with clean, stable utility power may not show how equipment responds to those disturbances.

Then there is vibration. A generator running under full load vibrates more, which can stress pipes and connections. Components that appear fine during a low-stress test may move, loosen, or fail when the system is working harder. These are not simply more boxes to add to a checklist; they are reasons to ask whether the test conditions are representative of the failure scenarios the building needs to withstand.

How a hidden connection fault caused an outage

The episode recounts a regional summer power outage affecting a tenant with a data-heavy business. The tenant had a UPS and a generator, and both had passed routine tests. The UPS was sized to support the load for about 15 minutes while the generator ramped up. The generator started, but it repeatedly tripped a breaker.

The problem was a corroded connection. Under the vibration of full-load operation, it arced and failed. The tenant lost power for almost an hour. A routine test could have found issues such as a dead battery or a bad fuel pump, but this fault did not become apparent without sufficient stress.

The lesson is not that every system will fail in the same way. It is that test results only tell you what the test actually measured. A passing result is useful, but its meaning depends on the conditions applied and the failure modes those conditions could reveal.

Prioritize systems by consequence

No building team can simulate every possible emergency. A practical testing program begins by identifying the consequences of failure. Which systems, if unavailable, would stop operations or put people in danger?

The answer varies with the facility. In a hospital, life-support and surgical equipment may be critical. An office building may need to focus on elevators and HVAC. A data center will have a clear interest in its IT infrastructure. The purpose of this prioritization is to connect testing effort to the actual needs of occupants, tenants, and the business.

Once critical systems are identified, teams can choose tests that challenge those systems more directly. One example from the discussion is incremental load testing. Instead of simply starting a generator and letting it run, increase the load gradually—at 25%, 50%, and 75%—and observe how it performs. This gives the team more information about performance at different levels than a basic start-up test can provide.

Make testing more realistic, one step at a time

Seasonal timing can also reveal information that a spring-only test schedule misses. If systems are most likely to be pushed during extreme heat or cold, tests scheduled around those seasons can provide a better view of how they behave under challenging environmental conditions.

More realistic testing does not have to mean an elaborate disaster drill every month. The episode suggests using smaller, targeted exercises. One quarter might focus on the generator under load; another might test the fire alarm system during a simulated power outage. Teams can build a program gradually and use each exercise to learn about a particular risk.

Intentionality matters more than volume. A test should have a clear purpose: what condition is being challenged, what system behavior is being observed, and what would the team do with the result? Reviewing those questions makes tests more useful and keeps effort connected to operational priorities.

Explain the value in business terms

Testing competes for time and budget, so facilities teams need to explain why deeper testing is worthwhile. The guests frame it as an insurance policy. A single hour of downtime for a critical tenant could cost thousands or tens of thousands of dollars, without counting reputational damage. The cost of a few hours of testing may be small by comparison.

A direct question can help make the issue clear to leadership: “What breaks if this goes down?” It shifts the conversation from test paperwork to business impact. Tenants also understand the consequences through interruptions: power flickers, elevators stop, and work is disrupted. They may not care that a test report says “pass” if their business was interrupted during an actual event.

Three actions for your next review

First, review what your current tests actually prove. Examine the pass/fail criteria and ask what you know about the system after it passes. Does the test address the load, temperature, power conditions, or vibration relevant to the most important risks?

Second, identify the failure scenarios that would hurt the most. Consider the impact on people, tenants, and business operations, and prioritize accordingly.

Third, create a simple plan to close the gap. Add more realistic conditions incrementally and choose targeted tests that give the team useful evidence. After any real event, debrief—even when the failure seems minor. An unexpected result is a chance to learn something about the system and improve the next test.

The objective is not to run more tests merely to increase the count. It is to have real confidence in what a building can handle when conditions become difficult. To hear the full conversation and its practical examples, listen to the episode and use it as a prompt to review your own testing program. Resilience is proven under stress, not in a routine test.