For all the progress observability has made, one thing hasn’t changed: it mostly works for the people who built it, not for the people who actually need it during an incident (developer observability anyone?).
Across dozens of practitioner and prospect conversations, the same story keeps coming up:
- SREs know the dashboards – because they built them.
- Developers don’t.
- Product engineers don’t.
- Customer Success absolutely doesn’t.
- And yet all of them get pulled into incidents or asked to explain behavior, and impact, to customers.
Observability was supposed to democratize insight across the org. Instead, it’s increasingly siloed – and the results show up in stagnant MTTR, slower delivery velocity, and overloaded teams.
The Problem: Observability Tools Built for Experts, Not Teams
Teams tell us the same thing in slightly different words:
“Product engineers aren’t versed in observability… they’re shallow on these tools. They’re specialists in their own domains – not observability.”
“SRE isn’t the first line of defense – Customer Success is. These tools are exposed outside of SRE. Support, success, sales all rely on them.”
“Developers are overloaded with support and break/fix work. They don’t have time to become fluent in dashboards.”
Even inside engineering, observability literacy is uneven. Developers often rely on SREs to create their dashboards, tune queries, and extract signal:
“I create dashboards for developers because they’re too busy for this thing.”
– Platform Engineer at a Fintech
None of this is surprising. Most observability solutions expect every user to:
- Understand a vendor-specific query language
- Navigate stale dashboards built months ago
- Know the quirks of a big-data backend
- Spelunk through log, metric, and trace cardinality to find “the right panel”
That’s not democratization – it’s gatekeeping via complexity!
And because everything depends on hand-crafted queries piped into brittle dashboards, the system becomes outdated the moment the application changes. Which, in the AI era, feels like, all the time?
Stale Dashboards, Brittle Queries, and the Illusion of “Stored Insight”
Traditional observability follows this loop:
- Emit everything.
- Store everything.
- Pray you can query it later.
- Hope a stale dashboard still matches the shape of your system.
But teams tell us it doesn’t:
- “We add features too fast – dashboards don’t keep up.”
- “Queries break when devs change log formats.”
- “It feels like tech debt – not observability.”
Because the backend stores everything, pricing also reinforces bad habits:
Teams stop instrumenting dev/staging because the pricing model punishes them for sending data.
The result? Observability becomes reactive, fragile, and expensive – and excludes the people who need it most.
And bolting “AI front-ends” on top doesn’t solve this. Natural language query wrappers still assume the system can be expressed as a dashboard query. It’s reactive. It’s tied to the past. It can’t adapt to a system that’s changing every week.
The Real Shift: Observability Must Move Closer to the Source
The AI era is pushing a different paradigm – one where:
- Telemetry is read as it streams, close to the source
- Intelligence is applied before the data hits a backend
- Patterns are learned dynamically
- Insight adapts as your system evolves
- And the output is delivered where people actually work (terminal, IDE, Slack)
This isn’t about “asking” your observability system questions.
It’s about your observability system showing you what matters – proactively, in real time.
Proactive vs reactive.
Adaptive vs brittle.
Team-wide vs SRE-only.
Why Observability Must Become a Team Sport
Modern teams are thinly staffed, shipping faster, handling more customer interactions, and increasingly distributed across specialties.
You can’t expect:
- Customer Success to write PromQL
- Product Engineering to maintain dashboards
- Junior developers to understand the entire telemetry landscape
- SREs to be the only translators of system behavior
Teams describe the need clearly:
“We need a translation layer.”
“We need a self-service platform.”
“We need observability that works for non-experts.”
Observability is no longer a back-office SRE function.
It’s now how teams collaborate under pressure – and the tools have not kept up.
The Future: Proactive, Adaptive, and Embedded in the Flow of Work
AI, together with the movement towards Open Telemetry standards, finally gives us the ability to break out of the query/dashboard paradigm:
- Telemetry streamed and distilled at the edge
- Adaptive intelligence that learns from your system as it changes
- Signals, not dashboards, delivered directly into Slack, VS Code, or the terminal
- Cross-team context instantly shared, without requiring specialized expertise
This is the world products like Gonzo and Dstl8 are designed for:
👉 Gonzo – real-time, OTLP-native log distillation in your terminal
👉 Dstl8 – proactive AI observability delivered where teams collaborate, not where dashboards go to die
Both built around a simple truth:
Observability should serve the team, not the other way around.
The Bottom Line
Traditional observability has become a specialist-only discipline – brittle, reactive, and increasingly mismatched with how fast teams ship today.
To bring observability back to the team sport it was meant to be, we need:
- Proactive, streaming-first intelligence
- Adaptive models that evolve with the system
- Pricing models that don’t punish early environments
- Insights delivered where people already work
- And tools accessible to everyone, not just SREs
The future isn’t dashboards.
It’s distillation, collaboration, and intelligent assistance – in real time, for the whole team.
Back
press@controltheory.com
