Reading logs and traces
Have the model read the logs and distributed traces around a failure and tell the story of what happened across services, in order, with the suspicious parts marked.
How it works
A failed test often leaves its evidence spread across several services' logs and a trace with hundreds of spans. The model is given the logs from the failure window, filtered by request or correlation ID where possible, and asked to reconstruct the sequence: which request arrived, which services it touched, what each returned, where latency jumped, and where warnings or retries began. It is particularly useful at noticing what is missing — a call that should appear and doesn't — and at comparing a failing run's logs with a passing run's to show where they diverge. Results are a narrative with references to the specific log lines, so each claim can be checked.
When to use it
Failures in end-to-end and integration tests where the cause is in another service; intermittent failures, by comparing passing and failing runs; unfamiliar systems where the tester doesn't know what normal logs look like; and preparing evidence for a bug report.
Limitations
Logs are large and the model reads a filtered slice; if the cause sits outside the slice, the story it tells will be coherent and wrong. Logs record what developers chose to log, so silent failures stay silent. The model can mistake routine warnings for symptoms and will present a plausible sequence even when timestamps across services aren't synchronised. Logs may contain personal or secret data, which needs handling before they go to any model.
Watch for
The story blames a warning that also appears in every passing run. Before accepting a cause, check that the cited log line is absent from a passing run’s logs.
What you still own
Checking the narrative against the cited log lines, and deciding what is cause and what is noise.
Cite this
Qlarify Labs. (2026). Reading logs and traces. Retrieved from https://labs.qlarify.fi/ai-in-testing/reading-logs-and-traces