# Build a request timeline from query history

Start a request investigation with the query ID rather than attempting to reconstruct activity from unrelated log lines. HTTP responses expose `X-Coordinator-Query-Id`; structured request history uses the same identifier.

```sql
SELECT event_time_text, type, query_duration_ms,
       read_rows, written_rows, exception_code
FROM system.query_log
WHERE query_id = 'replace-with-query-id'
ORDER BY event_time;
```

Record these events in time order when explaining a request to another reader. With logging enabled and a zero duration threshold, history records a start and terminal event. A nonzero threshold records only qualifying terminal events, so a missing start is not itself evidence of lost data.

For work still running, capture `system.processes` separately. It is a current snapshot, while query history describes recorded events. The current request's terminal event becomes available after execution completes.

These tables provide request measurements, not a distributed tracing export or stack-sampling interface. Keep a chart labeled with the observed event types and timestamp source rather than drawing unsupported spans. Include the exact SQL and relevant limits, with sensitive values removed.

See [query history](https://coordinatordb.com/docs/reference/system-tables/query-log), [active requests](https://coordinatordb.com/docs/reference/system-tables/processes) and [HTTP metadata](https://coordinatordb.com/docs/concepts/features/interfaces/http).