Healthy vs. failed requests
The trace you just read is a healthy request that ran the whole pipeline. But not every useful trace is a big waterfall. Here’s what a failed request looks like, and why its shape alone tells you something.
This is another ready-made TraceQL query, this time for requests that ended in an error. Run it and open one result, the same way as before.
Run this query to load error traces from the last three hours. Wait for the results table to appear.
Now, open one of the error traces by clicking its trace ID.
If the list is empty, that’s not an issue. Widen the time range at the top of Explore and run the query again; a larger window usually surfaces some error traces. If you change the query by mistake, run the query step again to reload it.
Notice how different it looks. A successful order runs the whole pipeline: many spans, the deep recommendations → catalog → SELECT fan-out. A failed one is often shorter: it may stop at the step that failed, so it doesn’t always reach the rest of the pipeline. When it does stop early, the failed trace is visibly smaller, and that shape alone hints that the request gave up before you read a single attribute.
This is also where you meet status codes (a healthy request returns a success code, a failed one an error code) and, where your view offers one, an Errors filter for finding them. To see why a request failed, open the span that failed and read its details: http.status_code gives the numeric status, and the error message itself usually lives in the span’s events (look for an exception event). Together they tell you what went wrong. The lesson: useful traces aren’t always big waterfalls. A small, short trace can tell you exactly where a request gave up.