Skip to main content

Backend tracing

Backend tracing is the process of following a request as it flows through your system’s services and components. Each step is recorded as a “span,” showing what happened, how long it took, and whether it failed. By stitching these spans together into a trace, you can see the full path of a request end-to-end.

How backend tracing works in Multiplayer​

When you start a Multiplayer session recording, we ensure that every backend trace connected to that session is captured, with no sampling.

Here’s how it works under the hood:

  1. Session starts: Multiplayer generates a unique trace context (trace ID + span IDs). In OpenTelemetry terms, this is a TraceContext that travels with requests as they flow through your system.

  2. Sampling flag is set to “keep everything”: In OpenTelemetry, each trace has a traceFlags field, which includes a sampling bit (often called the “sampled” flag). Normally, your tracing backend (Datadog, New Relic, etc.) has a cardinality threshold based on which it decides whether to sample (keep) a trace or drop it.

Multiplayer overrides this for session recordings: we set the sampled flag to true at the root span, so all spans in the trace are preserved.

  1. Propagation through services: As the request travels across services and components, OpenTelemetry propagates the trace context via headers (traceparent, x-trace-id,x-span-id, etc.). Every service that participates in the session inherits the “sampled = true” flag, ensuring that no span gets dropped along the path.

  2. Collection: Your OpenTelemetry SDKs/agents/collectors capture every span, log, and metric along that trace. Multiplayer has two options for consuming this information (see step 2 of the configuration guide):

  1. Session replay correlation: Multiplayer automatically correlates the backend data with the frontend data and user actions. When you view a session replay in Multiplayer, you see not only the DOM/UI actions but also all backend traces linked to the same session ID.

Since we never sampled out spans during the session, you get full fidelity visibility of what happened across the stack.

  1. (Optional) Capture request/response and header content per session: In addition to sending traces and logs, we recommend that you capture request/response and header content to enrich your full stack session recordings. See step 2 in the configuration guide.

How this differs from others​

  • APM tools (Datadog, New Relic, etc.) continuously ingest telemetry across your entire system. Because this generates massive volumes of data, they rely on trace sampling (e.g. keeping only a fraction of requests) to control cost and scale. This makes them excellent for monitoring overall system health, but less suited for surgical debugging of a specific user flow or providing the exact, full stack context needed to AI workflows. You can easily miss the trace that matters, or spend hours piecing it together.

  • Other session replay tools are typically frontend-only. If they do capture backend data, it’s often by piggybacking on your APM tools (hence, inheriting its sampling), or through manual, custom setups. As a result, backend visibility is either incomplete or inconsistent, and rarely correlated out of the box.

Next steps​

👀 If this is the first time you’ve heard about us, you may want to see full stack session recordings in action. You can do that in our free sandbox: sandbox.multiplayer.app

🚀 If you’re ready to trial Multiplayer, the fastest way to get started is to install our browser extension from the Chrome Web Store (Chrome, Firefox, and Edge supported).