Who Is the Dashboard For?

TL;DR

• A self-driving car has more sensors than ever and no dashboard. Autonomy doesn't reduce sensing; it removes the audience.
• When the consumer of telemetry changes from a human to an agent, observability inverts: from recall to precision, from a destination you log into to a substrate the agent acts on.
• An agent runs coarse in steady state and raises fidelity to full resolution exactly where a fault unfolds, so it sees more at the decision point and pays for less.
• In cloud-native infrastructure, the Kubernetes and cloud control planes already sense most of what matters. Don't port the data. Port the action.

A self-driving car has no dashboard. Not a simplified one, none. There is no instrument cluster the car consults before it brakes, no speedometer it glances at, no dial reassuring it that the engine is warm. And yet a self-driving car is drowning in sensors: lidar on the roof, radar in the bumpers, a dozen cameras, ultrasonic arrays, an inertial unit sampling hundreds of times a second. It senses far more than any car with a human behind the wheel. It simply never draws any of it on a screen, because there is no one looking at the screen.

Hold that image, because it is the most useful thing I can offer about where operations is going.

The dashboard was never for the machine

We have spent fifteen years building observability as a cockpit. Dashboards, panels, alarm tiles, heatmaps, the wall of graphs every SRE org is quietly proud of. All of it exists for one reason: a human being is the thing that acts, and a human needs to see in order to decide. The dashboard is the instrument cluster behind the steering wheel. We poured enormous effort into making it richer: more panels, more correlation, more "single pane of glass", because the better the human could see, the faster the human could act.

Strip away the jargon and observability is, at bottom, insurance against human diagnostic uncertainty. Because you cannot predict which panel an engineer will open at 2 a.m., which label they'll group by, or how far back they'll scroll, the only safe move is to collect broadly and keep it forever, just in case. Almost everything expensive about modern observability follows from that one fact: the breadth, the retention, the cardinality, the pre-built dashboards, the per-gigabyte bill.

In an earlier post, I argued that the category that actually matters isn't AI observability; it's the autonomous control plane, the thermostat that senses divergence and acts, rather than the thermometer that only measures. If you take that seriously, you have to follow it one step further, into an uncomfortable place: once an agent is closing the loop, who is the dashboard for?

Autonomy doesn't mean less sensing. It means no audience.

Here is the part people get wrong the moment they hear "autonomous." They assume it means less observability: a leaner stack, fewer signals, the agent humming along on a trickle of data. The self-driving car says the opposite. Autonomy needs more sensing, not less. What changes is not the volume of sensing; it is the consumer. The consumer stops being a human reading panels and becomes an agent reasoning over signals, and that flips the entire design goal. A human consumer forces you to optimize for recall: never miss anything someone might later want to look at. An agent optimizes for precision: exactly the evidence its next decision needs.

So observability does not shrink, and it does not disappear. It inverts. It stops being a destination, a place you log into, a product you live in, a bill you pay to look at charts, and becomes a substrate: sensing wired directly into the system that acts on it. The dashboard doesn't get better. It gets empty, because the thing it was built to serve has left the room.

And this won't happen with a bang. The cockpit just gets quieter every quarter. Fewer people open the dashboard at 2 a.m., because fewer incidents need a human to read a graph and form a theory. The panels are still there; the audience is thinning. That is what a transition to autonomy actually looks like from the inside: not a switch you flip, but a room slowly emptying.

To be clear about what this inversion is not: it is not "an AI feature." Every observability vendor now sells an assistant that sits on top of the lake. But an agent bolted onto a human-shaped collection inherits the lake's ceiling; it reasons over the same down-sampled, pre-aggregated, just-in-case data, and its vendor cannot shrink that lake without shrinking its own revenue. The inversion is about who the collection serves, not whether an LLM sits on the dashboard.

Less data, sharper picture

The instinctive objection is that this means flying blind: collect less, see less, diagnose worse. At the moment that actually matters, the opposite is true.

A dashboard built for humans is quietly down-sampled and capped in advance to keep the bill survivable: averaged into 60-second rollups, stripped of its highest-cardinality labels, traces sampled down to a fraction. It has to be: you are paying to retain all of it, all the time, for a human who might one day want to look. So at 2 a.m., in the middle of the incident, you are squinting at coarsened data exactly when you need it sharpest. An agent inverts that. It runs cheap and coarse in steady state, then raises fidelity to full resolution precisely where and when a fault is unfolding: the affected services, for the duration of the incident. At the decision point it has more detail than the human dashboard, not less. Static cost control trades away accuracy at the worst possible moment; fault-driven sensing refuses that trade.

This is not flying blind, and it is not a license to throw data away. Fidelity is reduced only where the system can show the data wasn't diagnostically useful, and it is restored the instant an incident touches that domain. "Cheaper" is earned against what you can still diagnose, never assumed.

And it is, genuinely, cheaper, because most of what the human stack collects is never used. A large share of custom-metric volume is never queried, and much of what is ingested and indexed as logs is never read. Metric cardinality is often one of the largest drivers of a Kubernetes observability bill; a mid-sized estate can carry a million or more active series, and much of that exists so a human can slice the data arbitrarily, after the fact. You are paying, often twice over (once to store it where it's produced, again to copy it into the tool), for optionality almost no one exercises. An agent that knows what its own loop consumes simply doesn't buy the unread majority.

Don't take my word for the wall this hits; take the vendors'. Grafana's own surveys have teams running an average of eight observability technologies, with complexity now the #1 concern (38%), ahead of even cost. New Relic's 2025 Observability Forecast puts the median cost of a high-impact outage at $2 million an hour, and the median annual outage bill at $76 million. The human-shaped stack is expensive, and the humans it was shaped for are drowning in it.

There is one more difference, and it compounds. A dashboard's accuracy is frozen the day you build it; a panel never gets smarter from how an incident turned out. An agent does: it acts, checks whether the fix actually worked, and feeds that verdict back, so its diagnosis sharpens with every incident, per failure type. Human-first observability is a static artifact. Agent-first observability is a learning system.

The inversion, in one table

Everything above comes down to a single change of consumer. When the thing reading the signals stops being a person and becomes an agent, every design choice downstream flips:

Read the last row again, because it's the one that matters. The two columns are not competing versions of the same product. They have different finish lines.

Observability is a feature, not the finish line

Step back from the dashboard and ask what the whole apparatus is actually for. Not the panels, not the alerts, not even the root-cause analysis; what is the job? It is to keep the system available. Everything else, the sensing, the correlating, the recommending, is a means to that end. We lost sight of this because, in the human era, the means was the product: you bought observability, you logged into observability, observability was the thing you renewed. But surfacing data was never the goal. Staying up was the goal. The data was always just how a human got there.

Gartner has a name for the system that takes this seriously: the Digital Immune System. It folds observability together with AI-augmented testing, chaos engineering, autoremediation, SRE practice, and software supply-chain security into one capability with a single purpose: resilience, software that withstands failure and recovers without a human in the loop. The framing is exactly right, and the metaphor in the name does the work.

Your immune system does not render a dashboard. It does not page you when it detects a pathogen and wait for you to approve a response. It senses, decides, and acts continuously, beneath your awareness, and you learn it was working only because you didn't get sick. Sensing is indispensable to it, but sensing is not the point; the response is the point. A body that detects an infection and does nothing is not healthy. It is dying with excellent telemetry.

That is the inversion this whole post has been circling. In a Digital Immune System, observability is an organ, the sensing tissue, not the organism. It is a feature of a larger loop whose output is continuous availability, not a graph. The agent is the immune response; observability is how it feels the world. So the question stops being "how good is your observability" and becomes "how good is your immune system", and observability is graded only by how well it serves the response, never by how much it shows you.

This is the line between the old world and the new. The old world sells you better sensing and better recommendations and calls that the finish line. The new world treats sensing and recommendation as plumbing: necessary, invisible, judged only by the availability they produce. A recommendation a human still has to read and approve is the old world wearing new clothes; it keeps the person in the loop. The finish line is a system that senses, decides, and acts to keep itself alive, and tells you afterward, if at all.

What the cloud already senses

Now narrow this to where most new systems actually run: cloud-native infrastructure. Kubernetes for the workloads, a cloud provider underneath for the plumbing. Something is worth noticing here, and it tends to get lost under the marketing.

In that world, the sensing already exists, and it is already native. Your cluster has a control plane that knows what is running, what changed, and what is failing: the Kubernetes API, the events, the audit log, the metrics and logs your platform already emits. Your cloud account has its own control plane that knows every configuration change, every permission, every managed service's health, and the provider's own audit and monitoring surface. That is two native planes of sensing that, between them, already see nearly everything that matters at the infrastructure layer.

Here is what that looks like at 2 a.m. A checkout service starts throwing 5xx errors. An agent reading those two planes doesn't query a lake; it walks the live dependency graph (checkout → payment → the database, bound through an IAM role and a security group), diffs what changed in that blast radius, and finds it: the cloud audit log shows the security group lost its database port at 14:02, one minute before the symptoms began. Restore the rule, watch the errors clear, done before the pager would have fired. The cause was an infrastructure change one layer below the request path: invisible to a trace map, obvious in the control plane's own history.

Which raises the question the whole industry has been talking around: if an autonomous system can read both of those planes natively and act on them, what exactly is the third-party observability destination in the middle doing? It is re-ingesting data you already have into a second copy you also pay for, to render a chart for a human who is increasingly not looking. For the infrastructure and platform fault domain, the crash loops, the configuration drift, the exhausted resources, the permission that quietly changed and broke everything downstream, you do not need a separate place to ship all of your data. You need a system that reads where the data already lives, and closes the loop.

I want to be precise, because this is exactly where the argument gets abused. I am not saying observability is dead, and I am not telling anyone to rip out their vendor tomorrow. Deep application behavior, product analytics, security, compliance reporting, executive views: those are their own domains, with their own consumers, some of them human and likely to stay that way for a while. I am saying something narrower and more certain: the human-facing observability destination, for cloud infrastructure, is being hollowed out from the inside by the agents that no longer need it.

The multi-cloud question, asked backwards

Which brings me to the idea I actually sat down to write: multi-cloud, a debate the industry has had backwards for a decade. The entire multi-cloud observability pitch is normalization: pull AWS, Azure, and GCP into one data model, one query language, one pane of glass, so a human can look at everything in one place. The value proposition is unification of the data.

If no one is looking at the pane, that is a solution to an evaporating problem. Read the picture the other way. Each cloud keeps its own local sense → act loop, reading its own control planes natively; that is where the truth is, and it is cheapest and fastest to read it there. The only thing that spans the clouds is the thin layer on top: policy and action. What "healthy" means, the desired state you intend to hold, the remediations you allow, the trust each fix has earned. That is what travels.

Don't port the data. Port the action.

That single move flips the economics of multi-cloud: stop paying to centralize and normalize petabytes no one will read, and carry the one thing that is genuinely cloud-agnostic, the agent and its judgment. The unit of multi-cloud stops being a data lake and becomes a decision.

You don't retire the stack. You change who it's for.

If the destination is hollowing out, what should you actually do with the stack you have? Not rip it out. The practical move is to re-fit it for the new consumer, one fault class at a time: tune retention and fidelity to criticality and live fault status (full resolution where a fault is unfolding, sparse where things are calm, something only a system that knows the fault state can do); map which sensors each fault class actually needs, continuously, and close the gaps; then retire the duplicate feeds and the premium paid for data nobody reads. Each step is funded by the savings of the last.

And notice who can't offer you this. Any vendor whose revenue is the ingest is structurally barred from shrinking it; asking your observability vendor to recommend collecting less is asking a television network to recommend less TV. Optimization of the stack is only credible from a party that profits when your telemetry shrinks. Which is why an agent priced per managed cluster, not per gigabyte stored, ends up as the honest steward of your observability, not its replacement.

Observability doesn't lose its job in this story. It becomes the sensing organ of the immune system, one of the six components Gartner names in a Digital Immune System, maintained deliberately instead of accreted just in case.

Where this lands

None of this is a knock on observability vendors. They built the cockpit the human era needed, and that era is not over everywhere at once. But the trajectory is not subtle. As more of the loop closes without a human, the dashboard serves fewer people; the third-party destination in the middle gets harder to justify for infrastructure; and "which vendor unifies my multi-cloud telemetry" gives way to "which system carries my actions across clouds."

There is a simple way to see where it lands, and it is economic. Plot every kind of telemetry you buy on two axes, what it costs you today and how often it actually decides an incident, and the human-era stack sits squarely in the wrong corner. The most expensive data, high-cardinality metrics and the dashboards built on them, priced for arbitrary human slicing, is the least decisive at 2 a.m. And the most decisive data, state, topology, and drift, the control planes' own records of what is running and what changed, costs almost nothing to read. The decade ahead is a migration from the top-left of that chart to the bottom-right: stop paying a premium for legibility no one uses, and read the truth where it lives.

A self-driving car does not have a worse dashboard than an ordinary one. It has no dashboard, and more sensors than ever, pointed at the road, not at a screen. Our infrastructure is heading to the same place. The companies that win the next decade of operations will not be the ones with the prettiest pane of glass. They will be the ones who understood early that when you take the driver out of the loop, you do not make the dashboard better.

You make it unnecessary, and you port the action, not the data.

Next in the Dashboard Series: Who Pays for the Dashboard?, where the money goes when the audience leaves.

FAQ

Does autonomous operations mean collecting less observability data?

No. Autonomy needs as much sensing as before, often more. What changes is the consumer: an agent reasoning over signals instead of a human reading panels. That shifts the design goal from recall, never missing anything someone might look at, to precision, exactly the evidence the next decision needs.

What is fault-driven fidelity?

Running telemetry cheap and coarse in steady state, then raising it to full resolution only for the services in the blast radius while a fault is unfolding. The agent gets more detail at the decision point than a human dashboard does, without paying to retain all of it all the time.

Do I need to rip out my observability stack?

No. Re-fit it one fault class at a time: tune retention and fidelity to criticality and live fault status, map which sensors each fault class actually needs, and retire the duplicate feeds nobody reads.

What does "port the action, not the data" mean for multi-cloud?

Each cloud keeps a local sense-and-act loop that reads its own control planes natively. Only the thin layer on top travels across clouds: policy, desired state, allowed remediations and the trust each fix has earned. You stop paying to centralize and normalize telemetry for a single pane of glass.