Day 1 | 🎄 Observability under the Tree: What Changed in 2025

Get a full recap of the key innovations in observability this year: AI-native otel, mobile session replay and more.

by Alexis Roberson

Sometimes you need distance to see what really changed. And that’s exactly how 2025 felt in regards to observability. While the focus was rightfully on AI agents and MCP servers, the observability space was experiencing its own maturation. And if you feel you missed this shift, no need to panic, Santa left some gifts under the tree. Those gifts being a universal standard for instrumentation, practical platform consolidation, and AI-native capabilities that finally deliver on the hype.

Gift #1: Open

Telemetry or the foundation nobody wanted to build

Increase in OpenTelemetry Adoption over the past five years

For years, observability felt like the Wild West. Every vendor had their own way of doing things, their own agents, instrumentation libraries. If you wanted to switch tools, you basically had to re-instrument your entire application. It was exhausting, but nobody wanted to be the first to blink (so to speak).

OpenTelemetry had been building toward something for years, but 2025, in my opinion, was when it reached a tipping point. After gradual adoption since the early 2020s, it crossed from “early adopters only” to “the default choice.” The specs had stabilized, the major players finally committed, and the tooling matured enough that adoption became low-risk rather than bleeding-edge.

The change was subtle at first. A cloud provider here, a major vendor there, all quietly releasing native OTel support. Then it accelerated. Suddenly the question wasn’t “should we adopt OpenTelemetry?” but “why haven’t we adopted it yet?” Teams started instrumenting once and sending data anywhere they wanted. The instrumentation lock-in that had defined observability for years started to ease. Now, you still had considerations around data migration and historical context, but the path forward got clearer.

Increase in OpenTelemetry Adoption over the past five years

Even more, here’s what made this interesting: standardization didn’t just reduce vendor lock-in. It unlocked something bigger, and that is tool scrutinization by reducing scope and being more selective about what tool goes in your toolbox.

Gift #2: Platform Consolidation after the dust has settled

With a common data standard gaining real traction, something practical happened: the tooling chaos started to make less sense.

Think about the typical observability stack from a few years ago. Metrics in one place, logs in another, traces somewhere else. APM here, synthetic monitoring there, and probably two or three other specialized tools for edge cases. Each with its own interface, its own query language, its own billing model, and its own person on the team who understood how it worked.

2025 was the year teams started asking “why are we doing this to ourselves?”

Platform consolidation had been promised for years. However, this time felt different. With OTel providing a standard data layer, platforms could actually focus on the analysis and visualization layer instead of fighting about ingestion formats. They could genuinely unify telemetry data in ways that reduced cognitive load.

It is becoming common practice for teams to cut their tool count from eight or nine down to two or three, and actually improve coverage in the process. It’s important to note that the cost story varied with some teams seeing real savings from eliminating redundant ingestion and storage and others mainly reducing operational overhead rather than raw dollar spend. At the end of the day the consistent theme was relief.

With tool consolidation, came the freedom to innovate in the world of query execution, where instead of building complex queries to retrieve specific data, teams could interact with data sets using natural language.

Gift #3 Natural language query execution

I’m no stranger to learning and mastering query languages like the Elasticsearch Query DSL and though optimized for improving latency and data processing, there still remained a continual learning curve.

2025 brought natural language interfaces that crossed the “actually useful” threshold. Though not perfect as complex queries still benefit from knowing the underlying language, it has proven genuinely helpful for common questions. You could ask questions like:

“Show me API latency for checkout over the last hour broken down by region.”

And get back related data without memorizing aggregation functions or time window syntax. The true value is removing the barrier of entry, so less technical team members like product managers and business-focused teams can also understand the type of performance issues that were generally understood by DevOps or SREs. In other words, the observability data that had been locked behind specialized knowledge became accessible to more people who needed it.

But accessibility alone doesn’t solve the deeper problem, which is knowing what to look for in the first place to understand real business impact.

Gift #4 Aligned Business KPIs with measurable metrics

Historically, observability was about system health. Is the service up? What’s the error rate? How’s latency looking? All important questions, but that unfortunately rarely answered the question of why any of this should matter to other teams. The shift toward business outcomes had been building, but 2025 is when it moved from buzzword to practical framework.

Tools made it easier to connect technical metrics to business impact. That latency spike? You could now configure dashboards and alerts that showed the correlation with conversion drops and revenue impact, rather than just knowing the service was slow. This error rate? You could track it against transaction volume and calculate lost revenue. This performance degradation?

You could filter by customer segment and see who was actually affected. Going as far as detecting rage clicks on a page affecting user experience.

The setup still required work like defining what business metrics mattered, instrumenting those alongside technical metrics, building the correlation logic. But the platforms made it possible without custom data pipelines and analytics infrastructure.

This changed prioritization too. Instead of treating every alert as equally urgent, teams could focus on what actually moved the needle. The 99th percentile latency issue that only affected a low-value endpoint? Still worth fixing eventually, but not at 2 AM. The intermittent error affecting checkout? All hands on deck.

The business-outcome framing made observability feel less like a tax and more like a strategic capability. But it also created a new opportunity that begged the question: how can AI truly be used to not just automate processes but make real decisions around data interpretation and root cause analysis with the intent of self healing.

Gift #5 AI-Native observability, when the promises started delivering

Which brings us to AI, the talk of the town that has finally started delivering in meaningful ways in 2025.

Not the “AI-powered” marketing speak that got slapped on every dashboard, but real AI-native observability that changed how teams work. Anomaly detection that’s actually tuned for your environment and doesn’t require a data science degree to configure. Root cause analysis that connects the dots across services, traces, logs, and business metrics without requiring manual correlation. Predictive insights that warn you about capacity issues before they become incidents. All built into dashboards like Vega AI for thorough investigations.

The capabilities themselves weren’t entirely new as statistical anomaly detection has existed for years. What changed was the integration, the usability, and the accuracy. The systems got good enough that you could trust them to surface real issues without drowning you in false positives.

All the previous observability gifts created the perfect foundation for AI to enter the chat. From OTel’s standardized data formats creating consistent structure leading to more reliable pattern recognition. To the consolidated platforms that provide a unified view making natural language interfaces even more powerful because you can ask not just “what happened” but “why did this happen and what should I do about it.” By the time you add connections between metrics and business impact, you already have a full observability system primed and ready for AI.

Bonus: What Launch

Darkly left in your stockings this year

While the industry was catching up on the observability fundamentals, LaunchDarkly was actively building toward the same vision, with one crucial difference: observability unified with feature flag context. Here’s what landed in 2025 that aligns with these broader trends.

Vega AI: Making AI-Native Observability Real

Speaking of AI capabilities that actually deliver, LaunchDarkly introduced Vega, an AI-powered debugging companion that goes beyond generic copilots. Vega combines two integrated capabilities: an AI debugging assistant that summarizes errors, identifies root causes, and suggests code fixes with GitHub integration, and a natural language search assistant that lets you query observability data without memorizing syntax. The key difference? Context. Vega understands feature flags alongside telemetry data, connecting what changed in your release with what broke in production, enabling faster triage and smarter fixes.

OpenTelemetry Support: Embracing the Standard

In the spirit of OTel’s tipping point, LaunchDarkly’s C++ Server SDK added native OpenTelemetry tracing support. Teams can now enrich their distributed traces with LaunchDarkly context, sending observability data to power Guardian while maintaining the flexibility to route telemetry wherever they need. It’s exactly the kind of integration that becomes possible when standardization reduces the friction.

Session Replay for Mobile: Closing the Visibility Gap

Web session replay has been table stakes, but mobile remains a black box. LaunchDarkly’s new native iOS and Android SDKs for Session Replay now capture UI interactions, gestures, and network events tied directly to feature flag evaluations. When an issue occurs, you can see exactly what your users experienced and which flag variation they encountered, bringing the same level of observability to mobile that web teams have enjoyed.

Regression Debugging: Automated Error Detection

The Guarded Releases capability now includes regression debugging that automatically surfaces frontend errors tied to new feature flag variations without manual instrumentation. When a rollout triggers a regression, relevant errors appear directly in the monitoring view, with one-click access to deeper analysis in the observability view. It’s the kind of integration that makes detecting issues faster and connecting dots easier.

LLM Observability: AI-Specific Telemetry

As GenAI applications moved to production, teams needed visibility beyond standard metrics. LaunchDarkly’s LLM observability tracks not just performance metrics like latency and error rates, but semantic details including prompts, token usage, and responses. It addresses the unique challenge of monitoring AI features where understanding quality matters as much as performance.

Release Guardrails and Feature Flag Monitoring: Business Impact by Default

Two updates reinforced the shift toward business-outcome observability. Release guardrail metrics let teams define default trusted metrics that automatically apply to any guarded rollout, ensuring consistent measurement across releases. Feature Flag Monitoring provides a unified view showing errors, web vitals, and the impact of feature changes in one place, with flag change annotations overlaid to see correlation. You ship a feature, you immediately see how it’s performing, all with the context of which flags are active.

Together, these updates represent LaunchDarkly’s commitment to the same principles driving industry-wide change: standardized instrumentation, consolidated platforms, natural language accessibility, business-outcome alignment, and AI-native capabilities. The difference is in the integration, where feature flags provide the missing context that helps teams understand not just what happened, but what they changed that caused it to happen.

What next?

When I look at these changes together, I see something more significant than individual feature releases or product launches. The observability landscape of 2025 represents a meaningful shift in what’s practical and accessible.

It’s more accessible seeing that more people on the team can explore data and ask questions without specialized training. It’s more focused because we have better tools for measuring what actually matters for business outcomes, not just what’s easy to instrument. It’s more intelligent in that AI handles more of the grunt work of correlation and pattern matching. And it’s more practical because costs are more manageable and the tool sprawl that was slowly crushing teams can hopefully start to recede.

As we head into 2026, I’m not thinking about what new features will launch. I’m thinking about what becomes possible when these foundations are in place. When observability isn’t a specialized skill but a shared capability. When understanding system behavior is directly tied to business strategy. When the friction between having a question and getting an answer continues to decrease.

That’s the real gift 2025 left us. Not just better tools, but a better way of working. One that’s still evolving, but noticeably more mature than where we were.

Join us for Day 2 of the Holiday Campaign where we’ll discuss the reality of observability for AI agents.