v2.4 adds native OpenTelemetry ingestion, trace topology and dependency analysis, alert silencing and grouping, plus several stability fixes.
This release is about two things: playing nicely with standards, and keeping on-call sane. Native OpenTelemetry ingestion removes the platform-specific SDK as a hurdle, trace topology turns raw spans into a dependency map you can reason about, and the alerting changes stop the channel from shouting. Here is what changed in v2.4.
Previously, tracing ingestion required the platform's private protocol. v2.4 natively supports OTLP/HTTP and OTLP/gRPC. Services already using the OTel SDK or Collector only need to point the exporter endpoint at Observe and swap in a token — no changes to instrumentation code.
The Collector can also deliver traces, metrics and logs all three signal types through a single port. For teams already standardizing on OpenTelemetry, migration cost is essentially zero: change an endpoint and a token, restart the Collector, done. We also support mTLS on the gRPC receiver, so telemetry stays encrypted end to end — a requirement in regulated and sovereign environments where data in transit must be protected. And because the receiver now honors the full OTLP resource model, service name, environment and deployment attributes flow through unchanged, which means filters and dashboards keyed on those attributes keep working after you switch protocols. New services that adopt the OTel standard today will work with Observe out of the box tomorrow, without a platform-specific SDK.
The trace detail view gains a topology mode: services become nodes and the call relationships generate a dependency graph automatically, with node color and edge weight reflecting error rate and call volume. You can spot hot services and single points of failure at a glance.
The accompanying dependency analysis answers questions like "which downstreams break if this service goes down?" and "how has call volume between these two services trended lately?" — directly useful for microservice governance and capacity planning. The topology is aggregated from trace data in real time, so there's no service mesh to deploy and no extra instrumentation required. It works retroactively too: turn it on and the graph appears from traces you were already collecting.
You can click any node to filter the trace list to that service, and click an edge to see the span-level detail of the calls crossing it. The view also flags services whose error rate changed sharply in the last hour, so you notice a degrading dependency before it pages you.
Alert fatigue is a classic ops pain point. v2.4 adds two capabilities:
Silence windows accept both one-off ranges and cron-style recurring schedules, and grouping can be tuned with a time window and a group key. We also added a per-rule "resolve after" setting so an alert that stops firing clears itself instead of lingering in the active list. All three are configurable per alert rule without affecting other rules. The practical result is a quieter on-call channel that still carries every P0 — fewer people tuning alerts out because they've learned to ignore the noise, and fewer real incidents slipping through.
Upgrade: private-deployment users contact the delivery team for the v2.4 package and follow the upgrade guide — data migrates in place with no downtime. SaaS users have been upgraded automatically; no action needed. As always, report any issue to the delivery team or through the in-console feedback channel; a detailed report with your trace id helps us turn it around faster.