Monitoring AV sucks for a lot of reasons, but they all collapse into one problem: AV systems are not built to be observed. You can’t reliably tell what’s up, what’s down, and what’s about to fail. In an environment where hundreds or thousands of rooms need to just work, that’s untenable.
If you’ve tried to do this at scale, you already know it. And no, the difficulty isn’t a reflection of you or your team. This is an industry-wide problem caused by fundamental issues.
Most teams treat monitoring like something you bolt on at the end. Buy a tool, connect devices, build dashboards. But the hard part starts earlier, at the device itself, and at the fact that nobody has agreed on what “healthy” even means.
The data problem starts at the device
Most AV devices are built to be controlled, not monitored. You can tell a device what to do, but asking it what it’s doing is a different problem entirely. If devices have APIs at all, they’re often inconsistent or incomplete, exposing control surfaces rather than management data. Even when management APIs exist, they’re rarely standardized. Every vendor does something different. Every integration is bespoke. Every time you want to pull data, you end up doing custom work.
Because these are embedded, firmware-driven appliances, you can’t install an agent and solve it that way. That’s what we mean when we say monitoring AV is fundamentally “agentless”. You have to ask the device for information, and you get whatever it’s willing (or able) to give you.
So you work around it. Scrape web interfaces. Automate CLI sessions. Pull data in ways the device never intended. Not because you want to, but because it’s the only path to visibility.
This isn’t an edge case. This is the baseline reality of AV.
Nobody’s been pressured to fix this
For decades, there hasn’t been meaningful commercial pressure to make AV devices truly observable. We say we want it, but we don’t require it. We don’t enforce it in specs. We don’t reject products that can’t be monitored.
Manufacturers ship what sells. Operators inherit the gaps.
Manufacturer portals aren’t observability
When people say a device is “easy to monitor,” what they usually mean is the manufacturer has a cloud portal. Those portals can be useful for pushing updates, verifying configuration, or confirming a basic heartbeat. But each one only knows its own devices. It sees its slice of the environment, not your room.
Multiply that across a real deployment and you get multiple portals, multiple panes of glass, none of them seeing the whole picture. That’s not observability. That’s fragmentation with a better UI.
Understanding your environment from a manufacturer’s portal is like understanding a room from a single photo. You see something, but not everything. The answer isn’t finding the right angle. It’s stitching multiple perspectives together: local data, cloud telemetry, manufacturer portals, all of it. The more pictures, the more complete our understanding becomes.
Even if you solve collection, you’re still not done
Say you figure out collection. You integrate APIs, scrape what you need, normalize what you can, and get signals flowing. That’s real progress, but it’s not the finish line. Because metrics don’t equal health; they show activity, not meaning.
Most AV environments never define what they’re actually trying to measure. There’s no structured definition of what a “system” is. No shared agreement on what “healthy” means. No clear model of what failure looks like beyond “something broke.” The one question a health model needs to answer is deceptively simple: is this room usable right now? And the answer changes with every mix of devices, applications, and dependencies.
Without a model, you’re not turning data into signal. You’re just collecting noise and displaying it.
Scale makes all of this unavoidable
At a handful of rooms, you can brute-force it with tribal knowledge and grit. Someone who knows the environment connects dots manually. It works until it doesn’t.
At institutional scale, with thousands of rooms, tens of thousands of devices, and real uptime expectations, that approach collapses. You end up running the operation off anecdotes, escalations, and last-known-good guesses. Every high-profile meeting runs the risk of becoming a resume-generating event. One bad room, one bad call, one bad exec experience, and you’re in a postmortem explaining yourself with no data to back you up.
That’s a brutal way to run AV operations. And that is why monitoring AV sucks. Not because anyone is doing it wrong, but because the industry never shipped a right way to do it in the first place.
So what can we do?
The industry isn’t going to change overnight. But teams can stop repeating the patterns that got us here, starting with the assumption that monitoring is a tooling problem. It isn’t. It’s an architecture problem.
This is the thinking behind the AV Observability Framework, a structured, tool-agnostic approach we’ve been developing for designing observability in institutional AV environments. The core idea: figure out why you need to monitor before you figure out what to monitor, and figure out what before you worry about how.
The Framework is built on five sequential layers, from institutional intent through health modeling, signal architecture, and activation, each depending on the one before it. A deeper writeup is coming, but the practical takeaways for this piece come directly from it:
- Start with intent, not with data. Most monitoring efforts begin by asking “what can we collect?” The better question is “what must not fail, and how would we know?” Institutional expectations and non-negotiables need to be defined first. Everything downstream depends on this.
- Model health before you build dashboards. Define what a “system” is: not just a room, not just a device, but the full signal chain that delivers the experience. Define what “healthy” means as states, thresholds, and evidence. Map out the failure modes you actually care about. Without this, you’re collecting data for the sake of it.
- Meet the devices where they are. The data is messy and the APIs are inconsistent. That’s reality, and pretending otherwise is how you end up with a monitoring system that only works in the demo. Learn to work with what devices actually give you, and get creative about extracting what they don’t volunteer. It doesn’t matter how we get the data, just that we can automate the process.
- Raise the floor over time. Specify for observability. Choose products that expose usable data. Reward vendors who make monitoring easier, and stop giving a pass to those who don’t. The industry changes not by hoping for better, but by requiring it.
- Use tooling built for the real world. Not tools that assume clean data and perfect APIs, but tools flexible enough to go get what you need, however you need to get it. Agentless, protocol-diverse, and able to handle the mess. (We’re building exactly this with a free, open-source project called Omniglass. More on that soon.)
Once you have intent, a health model, devices that surface data, and a way to collect and process it, end-to-end monitoring becomes achievable. It’s not easy, but it is possible.
Learn how to do this at InfoComm 2026
Everything in this article is the problem statement. If you want to go deeper on the solution, we built a three-day intensive around it. June 13-15 at InfoComm, we walk through the full AV Observability Framework layer by layer, using Omniglass as a working reference platform. You’ll build a health model against an example environment, design the data pipelines to support it, and leave with an activation plan you can take back to your organization.
Register here: Applied Monitoring for AV Systems