/ /

Correlate Session Replays with Traces

You can now view trace IDs captured in network headers directly within web session replays, helping you connect what a user experienced with the backend activity behind it. Inspect request and response headers in DevTools, then use a trace identifier to locate matching traces and logs in your observability tool. This lets you investigate failed API calls and performance bottlenecks alongside the user actions recorded in the session.

Take that investigation further with Computer.

  • With your observability tools connected, Computer can analyze session evidence alongside backend logs, traces, and performance data to investigate likely root causes and recommend fixes.

  • Bring frontend and backend evidence into one end-to-end analysis – from the moment a user encounters an issue to actionable recommendations for resolving it.

Availability
Contact DevRev support to confirm that network header capture is enabled for your organization. This guide covers web session replays.


Prerequisites

  • Install and initialize the DevRev Web SDK.

  • Configure user identification and enable web session recording in Settings > PLuG and Portal > Session Replays.

  • Confirm with DevRev support that your organization has network header capture enabled and is using a compatible SDK.

  • Configure your application or tracing instrumentation to include a supported trace header on the requests or responses you want to investigate.

  • Ensure the corresponding backend traces or logs are available in your observability tool.

How capture works
DevRev captures supported headers that are already present on a network call. It does not add trace headers, create backend traces, or automatically attach a DevRev session ID to them.

Supported headers

The Web SDK captures the following allowlisted headers when network header capture is enabled:

Header

Use

traceparent

Carries W3C trace context. Use its trace ID to find the corresponding backend trace.

x-datadog-trace-id

Provides a trace identifier for requests instrumented with Datadog tracing.

x-cdn-trace-id

Provides a CDN trace identifier when your application or infrastructure supplies it.

content-type

Describes the request or response content type. It is not a trace identifier.

Headers are only available when they can be read by the SDK. Requests represented only by browser performance entries do not include captured headers.

Need to capture additional headers?

Contact DevRev support with the header names and your use case to discuss extending support beyond this list.


View headers in a session replay

  1. Go to Explore and search for Session replays.

  2. Open the relevant web session and select the browser tab you want to investigate.

  3. Open DevTools next to the playback window, then select Network.

  4. Find the failed or slow network request. Requests with captured headers display a Headers chip.

  5. Click Headers to open the detail panel. Review Request Headers and Response Headers.

  6. Use the copy action next to a header to copy its name and value.

Navigation tip
Clicking a network row moves playback to the request's point in the session. Use the Headers chip to open the header panel.

If a request or response has no captured headers, that section displays No headers captured.

Find the matching backend trace and logs

  1. In the header panel, look for traceparent, x-datadog-trace-id, or x-cdn-trace-id.

  2. Copy the header. The copy action includes both the header name and its value, so use the relevant identifier when searching in your observability tool.

  3. Search for the identifier in the tool that stores the corresponding backend trace. Use the request time and service as additional context where needed.

Scope of the header panel
Correlation is a manual workflow: inspect a header in DevRev, then look up the matching backend evidence. The header panel does not automatically open a trace or import backend logs into the session replay.


Prepare your application for correlation

Your frontend and backend need to share a trace identifier for the request you are investigating. Work with your engineering team to:

  • Configure tracing instrumentation to propagate a supported trace header on relevant application requests, or return a supported identifier in the response.

  • Preserve the tracing context through gateways and backend services so the identifier points to the corresponding trace.

  • Include the trace identifier in backend log entries if you want to find logs from the same request.

These are application and backend setup steps. Enabling header capture in DevRev does not configure tracing or logging in your services.

Troubleshooting

Q. I don't see the Headers chip.

Confirm that network header capture is enabled for your organization, and inspect a newly recorded session. Check that the application sends or receives a supported header on the request. Calls recorded only through browser performance entries do not provide headers.

Q. I see content-type but no trace identifier.

Header capture is working, but the request may not include a supported tracing header. Confirm your tracing configuration and, for response headers, check that the browser can read them.

Q. The header is visible, but I can't find the trace.

Use the identifier value rather than the copied header-name: value string. For traceparent, extract the trace ID. Verify that you are searching the correct environment and time range, and check whether the backend trace was retained or sampled out.

Q. I can find the trace, but not related logs.

Confirm that the backend writes the same trace identifier into its logs. Capturing a network header does not add trace identifiers to existing log entries.

Q. Can I send the DevRev session ID to my backend instead?

Automatically attaching a DevRev session ID to backend traces is not part of the implementation described in this guide. The workflow here uses existing trace identifiers captured from supported network headers.

Was this article helpful?