A correlation ID is an identifier you attach to every log line for one request or job so you can group them. A trace ID does the same job, but it belongs to a tracing system that also records which call caused which. If you already have tracing, use the trace ID as your correlation ID.
What a correlation ID does
The idea is simple. Generate a random ID when a request arrives, put it in every log line, and pass it to every service you call, usually in a header. Searching that ID returns the whole story across services.
It needs three habits:
- accept an incoming ID if a trusted caller sent one, otherwise create one
- include it in every log line through the logger context, not by hand
- forward it on every outbound call, including queues and background jobs
What a trace adds
A distributed trace is made of spans. Each span is one unit of work, and spans point to their parents. That gives you timing and structure: this checkout call spent 40 ms in the cart service and 900 ms waiting on the payment provider.
The W3C Trace Context standard defines the header for carrying this. It has a trace ID that identifies the whole trace and a parent ID that identifies the calling operation. A correlation ID has no parent concept, which is the main difference.
When a correlation ID is enough
- a small system with two or three services
- batch jobs and queue consumers where timing is not the question
- a first step while you decide on a tracing tool
When you want tracing
- you need to find which hop in a long chain is slow
- retries and fan out make the call graph hard to picture from logs
- several teams own services in the same request path
Combine them
You do not need to pick one. Log the trace ID in a field named trace_id on every line. Your logs then link to your traces, and anyone searching by the ID finds both. If some paths are not traced yet, keep generating a request ID for them and use the same field name.
One caution on trust. An ID from outside your boundary is input like any other. The W3C standard says a service that receives an invalid trace header should start a new trace instead. Treat an external ID as a hint, validate its format, and never let it grow without limit in size, since attackers can send junk to fill your logs.
Quick check
Should the ID be returned to the client?
Often yes, in a response header. When a customer reports an error, they can give you the ID and you can find the request quickly.
Is a user ID a good correlation ID?
No. One user makes many requests, so it groups too much, and it is personal data that you would be spreading across every system.
Sources
Last reviewed: 19 October 2026.
