2026-10-21

OpenTelemetry 101: connecting frontend errors to backend traces

A browser error report tells you what broke on the client. On its own, it rarely tells you why. The "why" usually lives on the server - a failed query, a timeout calling another service, a null a few layers down the call stack. Connecting the two is what turns "something broke" into "here's the line."

The mechanism: a shared trace ID

OpenTelemetry's tracing model is built around a traceparent header defined by the W3C Trace Context specification. Any request can carry one, and any OpenTelemetry-aware service that receives it can continue the same trace rather than starting a new one. In practice:

• A browser SDK generates (or receives) a trace ID for the current page interaction.
• When that page makes a request to your backend, the SDK attaches a traceparent header to it.
• Your backend, instrumented with any OpenTelemetry SDK, reads that header and continues the same trace instead of starting a fresh one.
• If the request throws on the backend, the resulting span - and the exception on it - is part of the same trace as the frontend interaction that triggered it.

No proprietary protocol, no custom header format - it's the same mechanism that lets any two OpenTelemetry-instrumented services link their traces across a network boundary, applied here across the browser/server boundary too.

Why this matters more than it sounds like it should

Without it, a frontend error and the backend exception it caused show up as two unrelated log lines, in two different systems, with no indication they're the same event. Someone has to manually correlate timestamps and guess. With a shared trace ID, they're the same record viewed from two ends - the browser's unhandled exception and the backend span that failed, linked automatically the moment both are reported.

What you actually need to wire up

1. A browser SDK that captures errors and injects traceparent into outgoing requests.
2. A backend already instrumented with any standard OpenTelemetry SDK for your language, exporting over OTLP.
3. A collector on the receiving end that stores both and understands they share a trace ID - this is the part Browse Error exists to do, so the linking happens automatically instead of by hand.

None of this requires a custom agent or a vendor-specific format. It requires the frontend and backend to agree on one header, and a backend that's already speaking OpenTelemetry.