Observability 2025 Decoded: What the DZone Report Means for SLO-Driven Ops
DZone’s 2025 Intelligent Observability Trend Report captures a real inflection point: teams are shifting from “more data” to outcome-driven practices that improve resilience and accountability.
The survey was gathered between August 28 and September 25, 2025, from a global pool of developers, architects, and IT professionals. The respondents represented seasoned practitioners (median ~15 years of experience) with diverse roles: 30% developers/engineers, 22% technical architects, and the remainder spanning SRE, DevOps, and IT leadership. This makes it a pragmatic snapshot of where observability is heading next.

The core shift: from telemetry volume to outcome-based observability
The key finding: teams are moving away from collecting endless metrics toward measuring impact through Service Level Objectives (SLOs) and business outcomes. The next frontier is understanding not just what your systems emit, but what your users and customers actually experience. The idea of outcome-based observability is quite interesting to me, as I recently wrote an article on value-based observability that explored it in depth.
What the DZone survey data reveals
Here are the key findings from DZone’s report:
1. Open standards are now the default.
- 63% of organizations use open standards for telemetry collection.
- Of these, 86% rely on OpenTelemetry (OTel), the clear foundation for portable, vendor-neutral pipelines.
2. AI is real, especially for automation.
- 74% use AI/ML to automate observability-driven actions to some extent.
- 82% are adopting AI somewhere in the stack.
- Top use cases: log analysis (46%), anomaly detection (40%), incident response (34%).
Feeding AI with high-fidelity Internet and app telemetry is critical, otherwise, it just hallucinates your runbooks.
3. Compliance drives maturity.
- 66% cite GDPR as a key driver for observability discipline.
- Nearly half (45%) audit their observability processes monthly.
This underscores the convergence between security and observability as compliance mandates mature, especially in regulated environments.
4. End-user experience remains a blind spot.
- 60% say end users still serve as their top “detectors” of issues.
- Yet only 37% use Real User Monitoring (RUM), though that jumps to 59% at “Proactive” maturity.
- Just 28% use synthetic transactions.
The takeaway: too many teams are still waiting for tickets rather than validating user journeys proactively across DNS, BGP, TLS, and CDN layers.
5. Success metrics reflect a reliability-first culture.
Top metrics used:
- MTTR (64%)
- Incident count (63%)
- Deployment frequency (50%)
These align with mature SLO-first practices and emphasize velocity and stability.
6. Security observability lags behind.
- Most orgs remain at the log-correlation stage.
- Unified or AI-driven security observability (SecObs) is still rare, highlighting a major opportunity.
Key Implications for ITOps and SRE Teams
Here’s our take on what these findings mean for ITOps and SRE leaders:
1. Standardize on OTel and enrich with Internet telemetry
Pick OpenTelemetry as the contract for metrics, traces, and logs, and treat vendors as pluggable backends via the Collector. Lock down a common resource schema (service, env, region, customer) and a consistent sampling policy so correlation actually works. Then close the blind spots OTel can’t see by design: integrate active and passive Internet telemetry (DNS, BGP, TLS, CDN, last-mile network paths) to contextualise “good code, bad experience” moments.
In short: run OTel for app signals, feed synthetic/RUM and network path data alongside it, and correlate everything at the service and user-journey layers.
2. Make SLOs the backbone (alerting, retention, budgets)
Start with a handful of golden journeys and write SLOs that reflect user-perceived latency, availability, and correctness. Route alerts through error budgets (burn rate alerts at multiple windows), not raw CPU or latency spikes.
Let SLOs drive data policy: keep high-res telemetry where it can change the budget, tier the rest. Tie spend to SLO risk. If a dependency burns budget, it gets engineering cycles or a contract review. This keeps ops work prioritized by impact, not noise. Consider embracing XLOs – eXperience level Objectives, which are more user-centric.
3. Operationalize RUM and Synthetic for proactive verification
RUM tells you what real users just felt; synthetic tells you what the next user will feel. Both are critical for teams that value real-world user experience. Stand up synthetic tests for critical flows (login, search, checkout, auth to downstream APIs) from the geos and networks your customers actually use (synthetic tests from the cloud are not useful at measuring user experience), and include DNS, SSL/TLS, and CDN edge checks in the same runs.
Use RUM to tune thresholds, catch long-tail regressions, and bake these tests into change windows and release gates so you catch route leaks, cert drift, CDN config errors, and IdP hiccups before tickets flood in.
4. Use AI where it pays, but feed it clean data
AI is great at triage and correlation when you feed it clean, comprehensive signals; it’s terrible at inventing packets you never measured. Start with narrow loops: event dedup, topology-aware correlation, suggested runbook steps, and root-cause analysis (RCA).
Final takeaways
Dzone’s findings reinforce what we’ve been advising ITOps/SRE leaders: anchor reliability to SLOs, standardize on open telemetry pipelines, and pair RUM with synthetics to validate real-world journeys, not just dashboards. AI is already paying off in triage/automation, and compliance is now tied with observability strategy (DNS and BGP hijacks can be catastrophic).
Last but not least, the industry seems to be converging on the idea that more data is not better. Better data is better.
Summary
The DZone 2025 Intelligent Observability Report reveals a shift from data volume to outcome-based reliability. Teams are standardizing on OpenTelemetry, operationalizing SLOs, pairing RUM with synthetic testing, and using AI to drive smarter, faster incident response. The message is clear: More data isn’t better — better data is better.

