Before reaching for an automated view, it is worth knowing how to build a request timeline manually, trace, logs, and metrics, stitched by hand from HelixQL.

Helix has automation that assembles an incident timeline for you. It is worth learning to do it manually first, because understanding what the automation is actually doing under the hood is what makes it trustworthy instead of a black box during a real incident.

1. Anchor on the trace

Start with the slow or failed request itself. The trace gives a start time, an end time, and every span in between, which becomes the time window for everything else.

from traces
| where trace_id == "a1b2c3d4e5f6"
| project span.name, start_time, duration, service.name

2. Pull logs into that exact window

With the trace start and end time in hand, logs from every service involved, not just the one that emitted the trace, can be pulled into the same window for a fuller picture of what else was happening.

from logs
| where timestamp between ("14:32:01.200", "14:32:03.900")
| where service.name in ("checkout-api", "payments-api", "inventory-service")
| sort by timestamp asc

3. Overlay the relevant metric

A request-level view is incomplete without the system-level context around it, a CPU spike, a connection pool exhausting, a downstream queue backing up, all visible only in metrics, not in the trace or the logs.

from metrics
| where metric.name == "db.connection_pool.active"
| where service.name == "payments-api"
| where timestamp between ("14:31:30", "14:33:00")

4. Lay the three outputs side by side, in order

The manual version of this exercise is three separate query results, read in the order above, trace first for the shape of the request, logs second for what was said along the way, metrics third for the surrounding system state. That reading order is exactly what the automated timeline feature does for you once it is trusted, the value of building it by hand once is knowing when to fall back to the manual version, because the automation, like any correlation tool, occasionally misses a boundary case.

  • Anchor the investigation on the trace start and end time, everything else is scoped to that window.
  • Pull logs from every service in the request path, not only the one that failed.
  • Overlay system metrics for the same window to see resource context the trace cannot show.
  • Read the three outputs in order: trace shape, logs, then system state.