Summary Metrics

A high-frequency trading platform needed to measure tail latency with microsecond precision. Their Prometheus histograms had buckets at 1ms, 5ms, 10ms, 50ms. But their SLO was "P99 latency under 2ms", and the histogram could only tell them whether the P99 was above or below 1ms. The gap between 1ms and 5ms was a blind spot that happened to contain their most critical performance threshold.

They could have added more buckets, at 1.5ms, 2ms, 2.5ms, 3ms, but each bucket creates an additional time series per label combination, and their monitoring costs were already high. Instead, they switched to summary metrics for this specific use case, which calculate exact percentiles on the client without requiring bucket boundaries.

Summary metrics fill a specific niche: when you need exact percentile values from a single process and don't need to aggregate across instances.

A summary metric computes quantiles (percentiles expressed as fractions) over a sliding time window directly in the client application. Instead of counting observations into buckets, it keeps a buffer of recent observations and calculates exact percentiles from that buffer.

A Prometheus summary tracking P50, P90, and P99 produces:

http_request_duration_seconds{quantile="0.5"} 0.042 // 50th percentile = 42ms
http_request_duration_seconds{quantile="0.9"} 0.098 // 90th percentile = 98ms
http_request_duration_seconds{quantile="0.99"} 0.342 // 99th percentile = 342ms
http_request_duration_seconds_sum 23456.78 // total duration of all requests
http_request_duration_seconds_count 456789 // total request count

The values are exact for that specific process instance. No bucket interpolation. No estimation.

The sliding window: Summaries don't compute percentiles over all time, that would require unbounded memory. Instead, they use a configurable time window (e.g., 10 minutes) split into sub-windows, and they calculate quantiles over recent observations within that window. Old observations expire as the window advances.