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

Summary

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.

Context

Next.js automatically captures traces across requests, server-side rendering, middleware, and fetch calls, but these traces are not visible unless an exporter is configured. Diagnosing slow pages without execution traces forces developers to guess bottlenecks from symptoms and reproduction attempts.

Approach / What changed

Configure the OpenTelemetry SDK using @vercel/otel in the project root instrumentation.ts file to export traces to an OTLP-compatible backend like Sentry. Set the standard OTEL_EXPORTER_OTLP_TRACES_ENDPOINT and OTEL_EXPORTER_OTLP_TRACES_HEADERS environment variables, and optionally enrich traces with custom spans in the Node runtime using @opentelemetry/api.

Takeaways

• @vercel/otel configures the OpenTelemetry SDK across Node and Edge runtimes, automatically loaded through Next.js startup via the register function in instrumentation.ts.
• Custom spans created via @opentelemetry/api allow developers to track domain logic and attach attributes, but @vercel/otel only supports custom spans in the Node runtime, not the Edge runtime.
• Direct OTLP exporting via @vercel/otel avoids SDK overhead but omits browser tracing, error monitoring, session replay, and source-mapped stack traces provided by @sentry/nextjs.

Related reading

• Sentry · May 27, 2026

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

  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.

  Lazar Nikolov

• Sentry · May 11, 2026