When the BMS Keeps Rebooting: How the Right OT Monitoring Tools Found the Real Bottleneck

For the BMS Automation & Controls team running one of the largest casino and resort complexes in North America, “restart the server” had become standard operating procedure. Building-wide slowdowns. Unresponsive controls. Missed schedule changes. The pattern repeated until the team would log in, reboot the servers, and watch the system come back to life — for a while. Within hours or days, the symptoms returned.

The site is an 85-acre resort in the center of the Las Vegas Strip: 3,980 hotel rooms across six towers, more than 124,000 square feet of casino floor, 300,000 square feet of convention space, a 4,300-seat venue, and a 4.5-acre pool complex. A property of this scale runs on a sprawling BMS, with a network of JACE controllers managing 780 critical comfort and operational devices around the clock. When the automation layer slows down, the impact is immediate. Guests notice. Convention clients notice. Operations notices.

After enough reboot cycles, the team came to the conclusion most teams reach when nothing else is working: the network must be failing. The original Optigo Connect OT network infrastructure had been in place for years, and the obvious assumption was that it had finally run out of headroom for a property this large.

That assumption was wrong. But it took the right OT monitoring tools to prove it.

Finding the Real Bottleneck

Before signing off on a major infrastructure replacement, the team brought in Optigo Networks to deploy OptigoVN, the latest-generation OT monitoring and diagnostic suite, and pull packet captures directly from the JACEs across the system. The goal was to see exactly what was moving across the network before assuming the hardware couldn’t handle it.

OptigoVN’s Site Scope+ diagnostics surfaced the issue almost immediately. The hardware was healthy. The OT network was not the bottleneck. The problem was entirely in the software configuration above it.

Across the system, Change of Value (COV) thresholds and read/write polling rates had drifted from their intended settings. A global “fast policy” was triggering data requests on roughly a one-second cadence across a large number of points. Multiplied across 780 devices and the JACEs supervising them, that produced a continuous flood of unnecessary BACnet traffic. The system wasn’t broken. It was being asked to process thousands of requests it shouldn’t have been making in the first place.

This is the kind of issue that’s nearly invisible without packet-level visibility into the OT network. Each individual misconfiguration looks benign. The aggregate behavior is what overloads the system, and the only way to see the aggregate is to capture the traffic and analyze it. Conventional BMS troubleshooting tools weren’t designed to surface that pattern, which is why months of restarts had treated the symptom and never touched the cause.

The Fix Was Configuration, Not Hardware

Once the polling behavior was visible, the fix was a targeted adjustment rather than a capital project.

Working with local IT partners, the controls team modified the aggressive polling policies. For most points, the polling frequency dropped from one second to ten or sixty seconds. That single change eliminated the bulk of the unnecessary traffic generating the slowdowns.

Response times improved immediately. The reboot cycle stopped. The network Health Score moved from a critical 40% to 81% — a strong result for a property of this scale and complexity, and a direct measure of how much traffic the system had been wasting on data nobody was using.

To keep the configuration from drifting back into the same state, the Optigo Networks team helped the client set up Optigo’s free traffic capture software for continuous monitoring, uploading data every 15 minutes for ongoing analysis. The same visibility that surfaced the original problem now runs in the background, ready to flag the next configuration drift before it becomes a guest complaint.

The network Health Score moved from 40% to 81% overnight — without replacing a single piece of hardware.

Schedule Optimization and the ESG Argument

The most useful outcome of this engagement wasn’t the reboots that stopped or the response times that recovered. It was the operational discipline the visibility enabled.

For a property running 24/7 across 85 acres, schedule optimization is an ESG question as much as a comfort question. Every minute equipment runs when it doesn’t need to runs up the energy bill and erodes the sustainability targets the resort reports against. Before OptigoVN, the team had no reliable way to confirm that an “optimized” schedule was actually being executed by the network underneath. The polling configuration drift made that impossible — the system was so busy processing unnecessary traffic that the schedules sitting on top of it couldn’t be trusted.

With the polling issue resolved and continuous OT monitoring in place, the team can now make schedule decisions and verify that the network is executing them as designed. That’s the foundation underneath every ESG mandate the property reports against: an OT network that actually does what the BMS says it’s doing.

What this means for large BMS environments

The reboot cycle is one of the clearest signals that a problem lives below the BMS layer. If restarting the server fixes the symptoms temporarily but the symptoms come back, the automation layer isn’t where the root cause is. Something underneath is generating load the system can’t sustain.

In this case, that load came from polling configuration — not hardware, not a failed router, not a vendor’s programming error. Without packet-level visibility into the OT network, none of that would have been findable in any reasonable amount of time. The team was on the verge of replacing infrastructure that didn’t need replacing.

For facilities teams running large, complex BMS environments, the pattern is worth keeping in mind. BACnet routing problems, polling storms, and configuration drift all behave the same way from the BMS front-end: the system looks like it’s working until it isn’t. Closing the gap between what the BMS reports and what the network is actually doing is the difference between months of reboots and a fix that holds.

OptigoVN gave this team what conventional troubleshooting couldn’t: visibility into the OT network layer where the real problem lived. One diagnostic session identified a configuration issue that had been forcing weekly reboots for months. If your BMS keeps needing a restart to behave, the answer might be in a part of your network you’ve never been able to see before. See what OptigoVN can find on your network.