Correlating Frontend and Backend Traces

The ultimate goal of frontend observability is a single trace that connects a user's click in React through the network, through API handlers, through service calls, and down to the database query that caused a slow response. This end-to-end trace makes root cause analysis instant.

The W3C TraceContext specification defines the traceparent header format: version-traceId-parentSpanId-flags. A sample value looks like: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01. The trace ID is shared across the entire distributed trace; the parent span ID changes at each hop.

The OTel fetch instrumentation automatically injects the traceparent header into every outgoing fetch request. The header carries the current trace ID and the span ID of the frontend fetch span as the parent, allowing the backend to create a child span that is linked to the frontend span.

On the server, the OTel HTTP instrumentation for Node.js/Express reads the incoming traceparent header and creates spans that are children of the frontend fetch span. The trace ID is preserved, so Jaeger or Grafana Tempo shows the entire chain — browser span → Express span → database span — in one waterfall view.

With both frontend and backend instrumented, open Jaeger or Grafana Tempo and search for a trace ID. You'll see the full waterfall: the React component span at the top, the fetch span below it, then the Express route handler span, then the database query span — all with their durations and attributes.

Set user.id as an attribute on all spans in your React app using span.setAttribute('user.id', userId). Do the same on the backend. Now you can filter your observability backend to show all traces for a specific user ID, enabling you to diagnose issues reported by a specific customer.

Generate a unique session ID on page load and set it as session.id on all frontend spans. Include it in request headers so the backend also attaches it to backend spans. Session correlation lets you reconstruct the complete sequence of actions a user took in a single session.

Commercial tools like Datadog integrate RUM sessions with APM traces natively. The Datadog RUM SDK injects a specific header (X-Datadog-Trace-Id) into fetch requests, and the Datadog APM SDK on the backend reads it to link the RUM session replay to the distributed trace — you can watch the session replay and see the trace simultaneously.

Consider a user complaining that checkout is slow. With correlated traces, you search by user.id in your observability backend, find the checkout trace, and see immediately that the slowdown was a 900ms database query joining two large tables — something invisible to frontend metrics alone.

Browsers cannot send traces directly to Jaeger or other backends (CORS restrictions and credential exposure). Instead, run an OTel Collector as a proxy: configure OTLPTraceExporter to send to your Collector endpoint, which then fans out to Jaeger, Grafana Tempo, or any other backend.

Frontend traces can inadvertently capture sensitive data: form field values in URLs, PII in span attributes, session tokens in headers. Review your instrumentation to ensure no sensitive data is included in span attributes. Use span.setAttribute sparingly and sanitize URL query parameters before recording them.

What is the format of the W3C TraceContext traceparent header?

Correlating frontend and backend traces creates end-to-end visibility across the full user request journey. W3C TraceContext traceparent headers connect browser fetch spans to backend spans automatically via OTel instrumentation. Enrich all spans with user.id and session.id for targeted debugging. Use an OTel Collector as a browser-to-backend proxy to avoid CORS issues and credential exposure.