You don’t need to pick one: how Sentry and OpenTelemetry work together

Summary

Integrating Sentry into systems already instrumented with OpenTelemetry does not require replacing existing backend SDKs or rewriting service instrumentation. A hybrid architecture pairs the Sentry SDK on the frontend for browser tracing, Session Replay, and logs with existing OpenTelemetry configurations across backend services. Frontend requests propagate W3C traceparent headers to backend endpoints, which then export traces and logs over OTLP directly to Sentry endpoints or through an intermediate OpenTelemetry Collector. Ingested telemetry attaches backend spans and standard Python logs to the initial frontend user actions, establishing a unified distributed trace across the entire request path. Although Sentry's OTLP ingest currently supports logs and traces rather than metrics, dedicated backend Sentry SDKs remain an optional addition later for backend exception tracking and profiling.

Context

Teams evaluating Sentry often face the dilemma of whether they must replace their existing backend OpenTelemetry instrumentation and collectors with Sentry SDKs to achieve end-to-end distributed tracing.

Approach / What changed

Deploy the Sentry SDK on the frontend for browser-level context and error capture while retaining OpenTelemetry on the backend, connecting both via W3C traceparent header propagation and exporting backend OTLP traces and logs directly or through an OpenTelemetry Collector to Sentry.

Takeaways

• Sentry's OTLP ingest endpoint supports logs and traces but does not currently support metrics.
• Direct OTLP export fits single-service setups with minimal moving parts, while OpenTelemetry Collector forwarding enables batching, sampling, and routing across multiple Sentry projects or vendors.
• OpenTelemetry does not capture backend exceptions for Sentry error monitoring on its own; capturing backend exceptions and linking them to traces requires the Sentry backend SDK.

Related reading

• Sentry · Jun 29, 2026

  Next.js already traces your requests. Here's how to export them with OpenTelemetry.

  Next.js provides out-of-the-box tracing for incoming requests, fetch calls, middleware, and server-side rendering, but traces remain invisible without a configured exporter. Developers can use the @vercel/otel package inside an instrumentation file to initialize the OpenTelemetry SDK and transmit traces to any OTLP-compatible destination. While Next.js automatically creates spans for standard request lifecycles, developers can define custom active spans in the Node runtime to capture specific domain operations and contextual attributes. Exporting traces to backends like Sentry requires configuring standard OTLP endpoint and authentication environment variables. Choosing between direct OTLP export via @vercel/otel and the dedicated Sentry SDK depends on requirements, as direct export lacks browser tracing, error monitoring, and Edge custom spans.

  Kyle Tryon

• Sentry · May 11, 2026