A latency graph tells you something is slow. It has never told you which request. Exemplars close that gap.

Metrics are aggregates by design, and that's exactly what makes them useless for the next step of diagnosis. A p99 latency graph shows you a number went up. It cannot show you a request, because it threw the requests away the moment it computed the percentile. Exemplars fix that without giving up the efficiency of pre-aggregated metrics.

Sampling a real request at aggregation time

When Helix's metric pipeline aggregates a histogram bucket, it now attaches a small number of exemplar trace IDs — real requests that actually landed in that bucket — rather than only the aggregate. Storage cost is negligible: a handful of trace IDs per bucket, not the full request.

From graph to trace in one click

from metrics
| where name == "http_request_duration" and route == "/checkout"
| summarize p99(value) by bin(1m)
| with exemplars

In the UI, every point on the resulting latency graph that has an attached exemplar renders as a small marker; clicking it opens the exact trace that produced that data point, no separate search required. In HelixQL, the same information is queryable directly via with exemplars, so it's scriptable for anyone building automation on top.

Why this mattered more than we expected

We built exemplars as a nice-to-have alongside continuous profiling. It turned out to be the single most-used feature in incident retros in our own dogfood workspace — engineers reach for "show me the actual request behind this spike" more often than any dashboard we've built. One customer described it as turning a graph from "a symptom" into "a starting point."

Keeping exemplar selection honest

A naive implementation would just keep the first request that landed in a bucket, which quietly biases exemplars toward whatever happened to be first rather than being representative. We sample exemplars using reservoir sampling across the full bucket window instead, so a p99 bucket's exemplar is actually drawn from the population that made up that p99, not just whichever request happened to arrive first during the aggregation interval.

  • Real trace IDs attached to metric aggregation buckets at negligible storage cost
  • Click any point on a latency graph to open the exact underlying trace
  • Queryable in HelixQL via with exemplars for automation
  • No separate correlation step between a metric spike and a trace