How to Debug API Logs Using Correlation IDs
Use request IDs, trace IDs, and correlation IDs to connect API failures across logs, HAR files, stacktraces, and service boundaries.
Maintained by Ali Aygör. Report a correction.
Establish what the identifier means
A request ID, correlation ID and trace ID may have different scopes in your system. One might identify a single HTTP exchange; another may connect a workflow across retries. Before searching, establish where the identifier is created and which hops preserve it.
Do not invent a relationship merely because two log lines share an error message. The same exception can occur in unrelated requests. Keep service name, timestamp, environment and deployed version alongside the identifier.
Use a small fixture to check grouping
The local analyzer recognizes several common textual request/trace/correlation key patterns, including some JSON-style quoted keys. Missing severity stays UNKNOWN instead of being silently counted as an INFO event.
In this fixture, three events belong to demo-42. The stacktrace continuation is another line without an explicit level. It is useful context, but counting it as a separate normal INFO event would misrepresent the excerpt.
2026-05-17T12:00:00Z INFO requestId=demo-42 POST /orders
2026-05-17T12:00:01Z WARN requestId=demo-42 latency=900ms
2026-05-17T12:00:02Z ERROR requestId=demo-42 java.lang.IllegalStateException: Duplicate key
at com.acme.OrderService.create(OrderService.java:42)
Expected levels: INFO=1, WARN=1, ERROR=1, UNKNOWN=1Follow the request one hop at a time
Start with the client or gateway identifier, locate its first server entry and follow the services that actually recorded it. If a hop is absent, inspect propagation, routing and sampling before concluding that the service never received the request.
Compare a successful control request as well. A failure-specific absence is more informative than an ID format that is missing in every capture. Document which headers and log fields carry the identifier at each boundary.
Avoid timing assumptions
Minute buckets summarize text, not causal order. Device, gateway and application clocks can use different timezones or have skew. Normalize the timestamps before inferring which action happened first.
An error group counts occurrences in the pasted excerpt, not incident frequency across the fleet. Multiline stacktraces can contain several exception names for one event, so compare the original lines before treating every extracted exception as a separate failure.
Write the evidence and next step separately
A useful report says which request failed, which hop recorded the failure, what response reached the client and what evidence supports the hypothesis. Share a redacted excerpt with the minimum surrounding lines needed to reproduce the reasoning.
Keep tokens, internal hostnames and customer values out of shared logs. Recheck the same request path after a change, including retry behavior; replacing the symptom with another failure is not a complete fix.
Specifications and references
Continue the investigation
HAR Status 0 vs HTTP 500: Find Where an API Request Failed
Use browser network captures to distinguish an absent HTTP response, a CORS failure and a server 500, then correlate the request with logs.
How to Analyze HAR Files for API Debugging
A practical workflow for reading HAR files, finding slow requests, spotting 4xx/5xx failures, and sharing safe network summaries.
How to prettify application logs for debugging
A practical workflow for cleaning log output, extracting stack traces, formatting JSON logs, and sharing useful debugging notes safely.
Related tools
Dev Debug Helpers
OpenAPI Log Analyzer
Analyze API logs for ERROR/WARN/INFO counts, duplicate exceptions, correlation IDs, and timeline buckets.
Dev Debug Helpers
OpenTrace / Correlation ID Extractor
Scan pasted text or logs and extract likely trace, request, and correlation identifiers.
Dev Debug Helpers
OpenHAR File Analyzer
Analyze browser HAR files for slow requests, failed calls, duplicates, domains, and captured request timing.