If you have instrumented code with OpenTelemetry, you have probably called Span.AddEvent or Span.RecordException. In March 2026 the project announced it is deprecating that API. New events should be emitted as logs, correlated with the active span through context1.
It sounds like a small API change. For platform teams it touches instrumentation guidelines, dashboards, cost and, increasingly, AI telemetry.
Why the change
OpenTelemetry has offered two ways to emit events correlated with traces: span events via the Tracing API, and log-based events via the Logs API134. The announcement lists the problems with having both: split guidance for library authors, duplicate concepts for operators, and slower evolution because every improvement had to be specified twice1. The community has converged on a simpler model: events are logs with names, emitted via the Logs API and correlated through context, a direction set out in an earlier post on logging12.
What changes and what doesn't
| Changing | Staying the same |
|---|---|
Span event APIs such as AddEvent and RecordException are deprecated in the tracing specification | Existing span event data remains valid in the OTLP trace model |
| SDKs make log-based events first-class | Correlation across signals works the same way |
| Instrumentations and semantic conventions move to log-based events in their next major versions | Compatibility options can still show events on spans |
As the authors put it, they are deprecating the API for recording span events, not the ability to see events attached to spans1.
The practical risk isn't broken code. It's a dashboard or alert that quietly stops showing exceptions because they now arrive as logs instead of span events.
What I'd do now
- Update instrumentation guidelines. New code emits events and exceptions as log-based events correlated with the current span.
- Check the logs pipeline. If logs aren't collected through OpenTelemetry yet, events will have nowhere to go. A Collector gateway, as in Collector deployment patterns, is the natural place to route them.
- Audit dashboards and alerts that depend on span events, especially exception counts and error views, and test them after each instrumentation upgrade, as the project recommends1.
- Confirm backend support for showing log-based events in trace views, so engineers don't lose context when debugging.
- Watch costs. Moving events to the logs pipeline may change how they are priced and retained by your vendor. Model it before the switch.
Why this matters for AI telemetry
AI applications produce a lot of event-like data: prompts, responses, tool calls, guardrail decisions. Treating these as named, structured log events correlated with traces fits the GenAI observability work described in LLM observability with OpenTelemetry. It also makes it easier to apply separate retention, redaction and access rules to sensitive content than when it is embedded in spans.
How I can help
I design observability platforms on OpenTelemetry and help teams plan migrations like this one without losing visibility. As a fractional CTO I can own that roadmap. Or analyse your challenge and bring the result to a call.
- 1Deprecating Span Events APIOpenTelemetry blog · 17 Mar 2026
- 2OpenTelemetry logging and youOpenTelemetry blog · 2025
- 3Logs API specificationOpenTelemetry
- 4Tracing API specificationOpenTelemetry