Observability
Log Correlation ID Guide
Carry correlation and trace identifiers across APIs, queues and workers so one incident can be followed without logging sensitive payloads. This reference is written for developers who need practical validation behavior, reviewable rules and safe examples rather than copied snippets with no explanation.
Recommended workflow
| Step | Why it matters |
|---|---|
| Choose identifiers | Use trace IDs for distributed work and a separate business operation ID when needed. |
| Validate inbound values | Bound length and characters before copying caller IDs into logs. |
| Propagate every boundary | Forward context through HTTP clients, messages, scheduled jobs and retries. |
| Query consistently | Keep one field name and format across services. |
Starter snippet
accept safe request id -> create when absent -> propagate -> log structured field -> return response headerReview checks
- Do not use session tokens as correlation IDs.
- Return a safe identifier to support teams.
- Keep IDs searchable in structured logs.
- Preserve the original ID across retries.
Common mistakes
- Generating a new ID after every hop.
- Embedding user email or account data in IDs.
- Logging IDs only in error paths.
Validation should help users correct input while protecting systems from bad data. Keep syntax checks, product policy, security review and deliverability checks separate.
Related Formalint references
Continue with Api Correlation Id Logging Guide, Structured Logging Guide, OpenTelemetry Trace Debugging.