You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Create Issues from OpenTelemetry exceptions (OTLP exception log records and span events) #127561
Applications instrumented only with OpenTelemetry can send traces and logs to Sentry's OTLP endpoints, but their exceptions never become Issues:
Exception span events (the current default way OTel SDKs record exceptions, via span.recordException) are dropped on OTLP ingest. Sentry's docs say "All span events are dropped during ingestion".
Exception log records (where OTel is moving exceptions: OTEP 4430, OTEL_SEMCONV_EXCEPTION_SIGNAL_OPT_IN=logs) are stored as logs only.
So OTel-only services get no Issues, alerts, grouping, suspect commits or Seer for their errors, even though the data contains everything an error event needs: exception.type, exception.message, exception.stacktrace (semconv), plus trace and span ids.
Solution Brainstorm
Build on the generic log → Issue capability in #113802, with an exception-aware path for OTel:
Exception log records → error Issues. Records with event_nameexception / *.exception, or with exception.type / exception.message attributes, become error events. Severity sets level and handled state (FATAL/ERROR → Issue, WARN optional). The stack trace is parsed from exception.stacktrace (its format depends on the runtime), with cause chains as linked errors and the trace context kept.
Span events → the same path. Instead of dropping exception span events, convert them into exception log records (same attributes, plus the span's trace/span ids) so they go through step 1. Until OTel SDKs default to log-based exceptions, this covers most OTel exceptions in the wild.
De-duplication. In logs/dup mode, SDKs emit both a span event and a log record for the same exception. These should become one Issue (e.g. keyed on span id + message).
@Prithvirajkumar are there some customers asking for this functionality, if so could you share some context with me internally.
Span events → the same path
From my perspective, if span events weren't deprecated, this would seem like a reasonable feature to implement, but given that span events are deprecated IMO we should not be building on top of them.
Exception log records → error Issues.
A user can setup a monitor today on any log attribute, does this affordance give enough value to be worth having a special case like this?
Activity
getsantry commentedon Oct 15, 2026
Assigning to @getsentry/support for routing ⏲️
linear-code commentedon Oct 15, 2026
ENG-8820
getsantry commentedon Oct 16, 2026
Routing to @getsentry/product-owners-ingestion-and-filtering for triage ⏲️
bcoe commentedon Oct 19, 2026
@Prithvirajkumar are there some customers asking for this functionality, if so could you share some context with me internally.
From my perspective, if span events weren't deprecated, this would seem like a reasonable feature to implement, but given that span events are deprecated IMO we should not be building on top of them.
A user can setup a monitor today on any log attribute, does this affordance give enough value to be worth having a special case like this?