request_id and Correlation: Stop Guessing in Incidents

A typical support scenario: "the client says it's slow," "there's a 500 somewhere," "feels like the database." Until you can tie one user click to a specific API call and a specific SQL or external call, it all stays guesswork.

The fix is request correlation through a request_id (or correlation id).

What request_id is, in plain terms

It's a unique identifier that lives along the whole path of a request: click in the browser, API, database and external services, response.

If the same request_id lands in every log, you can reconstruct the full story of a request in minutes.

A minimal logging schema that actually helps

Start with a set that almost always pays off:

• request_id
• method + route
• status_code
• duration_ms
• user_id/account_id/session_id (when available)
• error_class/error_message (on errors)

Where to get the request_id

There are two working approaches:

1. Generate it at the edge or API and pass it down through the services.
2. Generate it on the frontend and send it in a header, when you need strict click-to-API correlation.

The key rule: a request_id must be preserved and passed along, not created from scratch at every step.

How to propagate request_id through the chain

The minimal working setup:

• the frontend sends X-Request-Id (or the API generates and returns it)
• the API puts the id into the logger context and adds it to responses
• all external calls (HTTP and DB) are logged with the same id

What this gives the business

• faster incident response, so less downtime
• fewer fire drills and less manual diagnosis
• faster releases: regressions get caught immediately, not a week later

Next step

If you want, we can help you implement request correlation and a minimal observability layer (logs, metrics, alerts) without a big migration.

Support service: our support service
Case study on logs and Grafana Loki: how Grafana Loki let us see every API method