A look inside the planner that joins logs, metrics and traces in a single sub-second scan.

For years, debugging a production incident meant stitching together three tools, each with its own query syntax. HelixQL collapses that into one language over one store.

One query language over one store means the question you ask at 3 a.m. is the same one you asked in the design review.

Four lines, every signal

HelixQL reads like the question you would ask a teammate: select the signal, filter it, group it, look at it on the same timeline your alert fired on.

from traces
| where service = "checkout" and duration > 500ms
| join logs on trace_id
| summarize p95(duration) by route

One timeline, not three

Because metrics, logs, and traces land in the same columnar store, a query can pivot from a latency spike straight to the spans and log lines that caused it — without copy-pasting a trace ID between tabs.

Built for the pager

Every query is shareable as a permalink with the time range baked in. Drop it in the incident channel and the next responder sees exactly what you saw.

What you get on day one

  • Metrics, logs, and traces in a single columnar store — no copy-pasting trace IDs between tabs.
  • Shareable query permalinks with the time range baked in.
  • Sub-second pivots from a latency spike to the spans that caused it.