When Buildings Talk to the Cloud: Managing Data, Costs, and Operational Surprises

Why Building Telemetry Becomes an Expensive Problem

This episode of Built, Wired & Secured looks at a problem many property, facilities, and IT teams have already felt: building systems that quietly push too much data into vendor cloud platforms, creating recurring charges, lagging dashboards, noisy alerts, and confusion over ownership. Alex Morgan opens with a striking example of a campus paying a recurring $3,000 monthly line item because every sensor was streaming every 10 seconds to a vendor-hosted cloud. The result was not just a bigger bill. Dashboards slowed down, the help desk filled up, and the team had to scramble for local logs when they needed answers most.

The discussion with Michael Harrington and James Rogers makes the core issue clear. Connected systems often work exactly as configured, but not as governed. Sensors feed a controller or BAS, that system forwards data to a hosted analytics platform, and teams gradually depend on the cloud dashboard for daily operations. The trouble starts when facilities installs the sensors, IT manages the network, and the vendor sets cloud-first defaults. At that point, nobody consistently owns the cost, the retention policy, or the fallback plan.

The Quiet Risk of Default Settings

One of the strongest points in the episode is that defaults are often the real failure mode. Devices may ship with a cloud URI already configured and sampling settings designed for demos rather than production. Left unchanged, those settings scale into large data volumes and ongoing expense. The speakers explain that teams need some form of decision point at the edge, whether that is an on-site buffer, an edge processor, or rules on the device itself.

• Cloud defaults can create high-volume data flows without anyone noticing at first
• Sampling intervals that seem harmless in a pilot can become expensive at site scale
• Without edge rules, every sensor may send more data than operations actually needs
• Ownership gaps between facilities, IT, and vendors allow bad defaults to persist

That lack of ownership matters because downstream costs usually stay invisible until invoices arrive or support tickets pile up. Operators often notice the problem first because they depend on dashboards and alerts every day.

A Practical Fix That Reduced Cost Without Replacing Systems

James shares a practical example of fixing the issue without tearing out the existing environment. The team added a lightweight edge buffer and adjusted sampling policies. High-resolution data stayed local for 72 hours, while the cloud received five-minute averages for trend analysis. That single change reduced volume dramatically while still preserving the detail needed for incident triage.

This is one of the most useful lessons in the episode. Teams do not always need a full redesign to regain control. In many cases, better retention, better sampling, and clearer forwarding rules can reduce both cost and operational friction.

• Keep high-resolution data local for short-term troubleshooting
• Send aggregated data to the cloud for trends and reporting
• Preserve operational visibility without paying to stream everything constantly
• Use policy changes before jumping to hardware replacement

The hosts also stress that the raw bill is only part of the story. Human cost matters too. Support tickets, slow vendor support loops, and extra onboarding time all become real operational burdens when cloud telemetry is poorly managed.

Where Cloud Analytics Still Adds Value

The episode does not argue against cloud platforms altogether. Michael points out that cloud analytics can reduce field technician time significantly when the operational model is well defined. In one case, cloud analytics cut field tech time by 40 percent. But that benefit only showed up because the playbook had already been established. The team knew who would respond to each alert, how local fallbacks would be accessed, and where high-resolution data lived.

That distinction is important for business and facilities leaders. The cloud can absolutely improve efficiency, but only when supported by operational controls. Without those controls, the cloud does not remove problems. It simply moves them somewhere harder to manage.

How to Decide What Stays Local and What Goes to the Cloud

James offers a simple decision framework built around three questions:

• Latency: Do you need millisecond responses, or are minutes acceptable?
• Audience: Is the data primarily for local operators or for central analysts?
• Ownership: Who pays for it, and who fixes it when it breaks?

If immediate control loops are involved, the recommendation is to keep processing local. If the goal is cross-site benchmarking or broader analytics, then aggregated or sampled data can go to the cloud. Michael adds an operational test that leaders should not ignore: can staff still access usable fallback dashboards if the vendor portal is slow, changed, or unavailable? If not, that should be treated as a critical vendor-selection risk.

The Hidden Cost of Egress Fees and Throttling

A standout example in the episode involves a midsize campus where wireless sensors were sending 10-second readings to a vendor cloud. Finance eventually flagged a recurring $3,000 monthly charge tied to data egress and API calls. Even worse, the vendor throttled data for certain tenants during peak loads, causing dashboards to lag when operators most needed visibility.

The fix was straightforward but disciplined. The team sent aggregated trends to the cloud, kept high-resolution data local for a short window, and throttled non-actionable telemetry. For example, status heartbeats moved from every five seconds to every 10 minutes during steady-state operation. That change reduced bandwidth use and lowered alert fatigue without affecting operational decision-making.

What Teams Should Demand From Vendors

The conversation also addresses vendor resistance. Some vendors make local access or data export difficult, which creates long-term dependency and risk. Michael recommends making data portability and local access baseline requirements during negotiations. If a vendor resists, teams should treat that resistance as a material risk and require contractual language around exportability and safe exit options.

The hosts also recommend piloting first. A small pilot lets teams test defaults, measure data volumes, validate alert usefulness, and expose operational costs before a full rollout.

Three Actions to Take in the Next 30 Days

The episode closes with three clear next steps for facilities and IT leaders:

• Run a 30-minute cross-functional data flow review with facilities, IT, and the vendor to map where data goes and who owns the cost
• Set retention and sampling policies so high-resolution data stays local briefly while aggregated or sampled data goes to the cloud
• Clarify escalation paths and SLAs for vendor-hosted dashboards, while requiring local fallback views and exportable data

There is also one bonus action with outsized impact: throttle non-actionable telemetry such as steady-state heartbeats. As the discussion makes clear, not every fix requires new hardware. Sometimes the biggest improvement comes from simple policy changes that restore visibility, reduce recurring costs, and make ownership obvious.

The central takeaway from this episode is practical and timely. Map your data flows, define who owns the bill and the fallback, and treat telemetry design as an operational decision, not just a technical setting. For commercial real estate, facilities, and IT teams, that shift can prevent recurring surprises while keeping building systems useful, resilient, and aligned with how the property actually operates.

When Building Telemetry Turns Into a Billing and Operations Problem

Modern building systems promise better visibility, smarter operations, and stronger decision-making. Sensors, controllers, and dashboards can absolutely help facilities and IT teams understand what is happening across a property in real time. But as this episode of Built, Wired & Secured explains, that promise starts to break down when building telemetry is pushed into the cloud by default without a clear operating model behind it.

Alex Morgan frames the issue with a memorable example: one campus discovered a recurring $3,000 monthly charge because every sensor was streaming every 10 seconds into a vendor cloud. The result was larger than a finance problem. Dashboards began to lag, the help desk lit up, and when teams needed answers, nobody was fully sure where the authoritative data lived or who was responsible for the cost line.

That combination of surprise billing and operational confusion is exactly what makes connected building data such an important leadership issue. This is not just about bandwidth or storage. It is about resilience, accountability, vendor dependency, and whether the people running the building can still operate when the hosted layer slows down or changes.

Why the Problem Starts Quietly

One of the most useful ideas in the episode is that the real problem is often not a dramatic failure. It is the quiet accumulation of defaults. A device ships with a cloud URI already configured. Sampling intervals are set aggressively because they looked good in a demo. A vendor-hosted dashboard becomes the easiest view for operators to use day to day. None of those decisions feels dangerous by itself. Together, they create a system that continuously generates cost and risk.

Michael Harrington and James Rogers explain how ownership fractures in these environments. Facilities may install the sensors. IT may manage the network path. Vendors may recommend or preconfigure the cloud behavior. Because each group touches only part of the flow, nobody consistently owns the complete telemetry lifecycle. That means nobody is accountable for basic questions such as:

• What data is being sent off-site?
• How often is it being transmitted?
• How long does high-resolution data need to be retained?
• Who pays when vendor cloud usage expands?
• What is the fallback if the hosted dashboard slows down?

In many organizations, those questions are not answered until a bill appears or operations starts losing visibility.

The Cloud Is Not the Enemy, but It Needs Guardrails

The conversation does a good job avoiding the false choice between edge and cloud. The speakers are not arguing that cloud analytics should be avoided. In fact, Michael notes that he has seen cloud analytics cut field technician time by 40 percent. That is a meaningful business result. Faster troubleshooting and fewer field visits can absolutely justify the use of hosted tools.

But that benefit showed up only when the playbook was defined in advance. Teams knew who responded to which alert. They knew how local fallbacks worked. They knew where the detailed data lived when an incident needed deeper review. In other words, the cloud created value because it was part of an operating model, not because it existed on its own.

That distinction matters for real estate leaders, facility operators, and IT teams making buying decisions today. Cloud tools can save time, centralize analytics, and support benchmarking across sites. But if the team has not defined ownership, retention, fallback access, and alert handling, the cloud can simply move existing problems into a harder-to-control environment.

A More Practical Architecture: Keep What Matters Close

One of the most concrete examples in the episode comes from James Rogers, who describes a fix that reduced volume and cost without forcing a system replacement. The team added a lightweight edge buffer and changed sampling policies. Instead of pushing all high-resolution telemetry into the cloud, they kept that detailed data local for 72 hours. The cloud received five-minute averages for trends and broader analytics.

That is an important design pattern because it separates two different use cases:

• Short-term, high-detail data for incident response and local troubleshooting
• Aggregated, lower-volume data for trend analysis, reporting, and remote visibility

By separating those functions, teams can keep the operational detail they need without paying to export every reading at full resolution forever. This approach also improves resilience. If the cloud dashboard becomes slow or unavailable, the building team still has access to local information for triage.

For many organizations, that kind of architectural adjustment is far more realistic than a complete rip-and-replace. It turns telemetry management into a policy and workflow problem first, which is often where the biggest gains can be made.

The Hidden Cost: Support Burden and Lost Time

Another strong point in the episode is the reminder that the invoice is only one part of the total cost. Human cost matters just as much. When dashboards lag, when alerts become noisy, when vendor support loops are slow, and when new staff need extra onboarding just to understand where the data goes, those are real operating expenses.

This is especially relevant in commercial real estate environments where building systems support tenant experience, maintenance efficiency, and operating continuity. A telemetry design that creates uncertainty during peak loads does not just inconvenience the technical team. It can delay response, reduce trust in dashboards, and create a much larger downstream burden than the original subscription line item suggests.

Three Questions That Simplify the Decision

James offers a useful framework for deciding what should stay local and what should move to the cloud. He asks teams to evaluate three things: latency, audience, and ownership.

Latency means understanding whether the use case needs millisecond-level response or whether minute-level visibility is acceptable. If a process requires immediate control loops, it belongs locally. Audience means understanding who actually uses the data. If local operators depend on it to keep a building running, local usability matters more. If the goal is cross-site benchmarking or portfolio-level reporting, then aggregated cloud data may be enough. Ownership means identifying who pays for the data path and who is responsible when something breaks.

Michael adds one more practical test: if the vendor portal slows down or changes, can the staff still access a usable fallback dashboard? If not, that should be treated as a critical operational risk during vendor evaluation.

How Surprise Charges Actually Show Up

The episode provides a detailed example of a midsize campus where wireless sensors were pushing 10-second readings to a vendor cloud. Over time, finance flagged a recurring $3,000 monthly line tied to data egress and API usage. At the same time, peak demand caused vendor throttling for certain tenants, which meant the dashboards operators depended on started lagging during the very moments they needed clarity.

The fix did not require a new platform. The team changed what data was sent, kept high-resolution telemetry local for a limited period, and throttled non-actionable telemetry. One example was changing status heartbeats from every five seconds to every 10 minutes during steady-state operation. That reduced bandwidth consumption and operational noise at the same time.

That is a valuable lesson because it shows how much waste can sit inside well-intentioned defaults. Not every signal needs to travel at the same cadence. Not every reading needs to be stored in the same place. And not every cloud-facing data stream creates equal business value.

What to Demand Before You Commit

The vendor conversation in this episode is especially relevant for organizations evaluating smart building platforms. Michael recommends treating data portability and local access as baseline requirements. If a vendor resists exportable data or makes local fallback difficult, that should be considered a real risk rather than a minor inconvenience.

Teams should also pilot before they scale. A small test can reveal actual volumes, validate alert usefulness, and expose hidden operating costs before the entire site inherits those issues. That is a better path than discovering the real economics after the rollout is already complete.

What To Do Next

The closing recommendations are simple and actionable. First, run a 30-minute cross-functional data flow review with facilities, IT, and the vendor. Second, define retention and sampling rules so high-resolution data stays local for a short window while aggregated data goes to the cloud. Third, clarify escalation paths, service expectations, and fallback access for vendor-hosted dashboards.

The broader lesson is straightforward: telemetry should be designed around operational outcomes, not just connectivity. When teams map the flow, define ownership, and right-size what leaves the building, they reduce surprise bills and improve resilience at the same time.

If your organization is adding connected systems, expanding building analytics, or trying to reduce vendor dependency, this episode offers a useful framework for making those decisions with less friction and fewer surprises. Listen to the full conversation to hear how these practical changes can help keep building data valuable without making it fragile.