How do you trace a request across the stack?

Direct answer

What a strong answer covers

How it works

A request gets an identifier at the first hop, the browser or the gateway, and every subsequent service reads it from a header and attaches it to its logs and spans. With W3C Trace Context the traceparent header carries the trace and parent span IDs, so a tracing backend can assemble one waterfall from the browser fetch, through the API, into the database and queue consumers. Frontend telemetry adds page load, web vitals, and JavaScript errors keyed by the same trace ID, and release metadata on each span tells you which deploy the slow request ran on.

Example

A support ticket quotes a request ID from the error toast; searching it shows the browser span at 4.2 s, the API span at 4.1 s, and inside it a single Postgres span at 3.9 s for a query missing an index, with the deploy version that introduced the query. Without the propagated ID the same investigation would have meant correlating timestamps across three log systems.

Common mistakes

• Generating a new ID in each service so traces break at every hop.
• Logging the trace ID only on errors, so slow successful requests cannot be found.
• Sampling traces so aggressively that the one request a user complains about is never recorded.

A useful answer structure

Answer from your own work.

Do not memorise a script: use only examples you can explain honestly in follow-up questions.