How to correlate frontend and backend logs (for real)

The bug report says: "Checkout was broken at 3:47pm." You open your backend logs, grep for errors around 3:47pm, find 200 lines, and have no idea which one was this user's request. You open your frontend session replay, find the user, watch the click, see a 500 response to POST /api/checkout... and now have to find that exact request in the backend logs. You grep again, narrow by user ID, find 12 candidate requests, and finally identify the right one. 25 minutes wasted.

The fix is one HTTP header.

The pattern: session ID propagation

The browser-side recorder generates a stable session ID (short string like s_8a4f2c) for each user session. Every fetch and XHR the recorder intercepts gets a header injected:

x-nevision-session: s_8a4f2c

On the backend, your request middleware reads that header and includes the value as a field on every log line emitted during that request:

{
  "level": "error",
  "msg": "DB query timeout",
  "service": "api",
  "sessionId": "s_8a4f2c",
  "userId": "u_42",
  "requestId": "req_abc123"
}

Now: from the user's session replay, you can pivot to "show me all backend logs with sessionId=s_8a4f2c." From a backend error, you can pivot to "show me the session replay for s_8a4f2c." 25 minutes becomes 25 seconds.

Implement it in 4 steps

1. Frontend recorder must inject the session ID header on outgoing requests. Nevision does this automatically; if you're rolling your own, fetch and XHR both have prototype overrides.
2. Backend middleware reads the x-nevision-session header from incoming requests and stores it in a request-scoped context (AsyncLocalStorage in Node, request.state in Python ASGI).
3. Your logger reads from that context and adds sessionId to every log line emitted during request handling.
4. Both frontend and backend log streams ingest into the same searchable backend (Nevision logs, or any structured log store).

What about CORS?

Custom headers on cross-origin fetches require explicit CORS allowlisting. Add x-nevision-session to your backend's Access-Control-Allow-Headers response. Same-origin fetches don't need this.

Privacy considerations

The session ID is not a user ID — it's an opaque random string per session. Logging it is fine under GDPR. If you also log userId alongside, you're logging PII (treat it accordingly: retention limits, DSAR support, encryption at rest).