← Blog

Why 'single pane of glass' keeps failing network teams

“Single pane of glass” has been the promised destination of network tooling for a decade. Roll every feed into one console, the pitch goes, and operations gets simpler. Teams have bought it, built it, and integrated toward it — and yet the war room still fills up when something breaks. The dashboard is rarely the thing that ends the outage. That’s not a failure of any particular product. It’s a failure of the idea.

Breadth is not depth

A single pane is an aggregation strategy. Its job is to gather signals from everywhere and show them together: interfaces, CPU, alarms, flows, tickets, a hundred tiles turning green and red. That’s genuinely useful for situational awareness — knowing that something, somewhere, needs attention.

But breadth and depth are different problems, and consolidating breadth doesn’t produce depth. A wall of tiles can tell you a device is reachable and its CPU is fine. It cannot tell you that a BGP local-pref changed twenty minutes ago and quietly re-routed your egress, or that a multicast branch went missing while every interface still reads “up.” The pane shows you that — never why. The more sources you pour into it, the more green you’re staring at while the actual fault hides one layer down.

The questions a dashboard can’t answer

Think about what you actually ask during a real incident. Not “is it up?” — you already know something is wrong. You ask:

  • Why did the path change? Which attribute moved — AS-path, local-preference, a community — and what did it do to traffic?
  • What will this change break? Before I push this config, what’s the blast radius downstream?
  • Is my multicast tree intact? Does the (S,G) state still reach every receiver, or did a branch quietly disappear?
  • Are my VPNs still isolated? Are the VRF route-targets still exactly right, or did two customers just become able to see each other?

None of these are answered by a consolidated view. They’re answered by state — deep protocol state, kept as history, that you can diff and explain. A prettier arrangement of the same shallow signals gets you no closer.

Depth, history, and the ability to explain

The alternative to a better dashboard isn’t a worse one — it’s a different capability underneath. Three things matter more than consolidation:

  1. Depth. Collect the state that actually governs behavior — BGP path attributes, multicast trees and RPF, VRF route-targets and MPLS labels, circuits, configuration — not just reachability and counters.
  2. History. Keep that state over time so any two moments can be compared. Most incidents are a change, and you can’t see a change from a single snapshot no matter how many panels surround it.
  3. Explanation. Turn “something is red” into “this attribute changed at this time and here’s what it did.” That’s what actually closes a ticket.

A dashboard optimizes for the glance. Assurance optimizes for the answer. When the pressure is on, the answer is what you needed.

None of this means throwing away your consolidated views — keep them for the glance. But put something underneath that can go deep, remember, and explain. That’s the layer Phantom is built to be: deep collection of network state, kept as history, on your own infrastructure. Start with our primer on network observability, see how deep collection works, and when you want the answers instead of the tiles, book a demo.

Change the network with confidence.

Book a demo