Summary Metric

What makes a summary metric different

A summary metric is designed to record observations at the point of instrumentation, then expose count, sum and quantile values for those observations. That makes it useful for things like request latency or payload size, where you want both volume and distribution signals without manually calculating percentiles in every query.

The key distinction is that the quantiles are calculated locally by each instrumented process, not from raw samples that can be recombined safely later. In practice, that means a summary answers a local service-level question well, but it does not behave like an aggregatable fleet-wide metric.

Why summaries are useful

Summaries help teams understand the shape of observed behaviour, not just the average. A count and sum show how much activity occurred, while quantiles show whether a small number of operations are much slower or larger than the rest.

That makes the metric especially valuable for latency analysis, request sizing, and any workload where the tail matters. A p95 or p99 value can reveal user experience problems that a mean would hide, particularly in systems with bursty traffic or uneven downstream dependencies.

Summaries are often chosen when the producer of the metric knows enough about the observation to compute useful quantiles at source, and when consumers mainly need a direct view of the local distribution rather than a merged global one.

Why summary quantiles do not aggregate cleanly

Prometheus summary quantiles are not mergeable in the same way that counters are. If two instances each report their own p95, the result is not the p95 of the combined population, because quantiles depend on the full distribution of observations, not on a summary statistic that can be added together.

That limitation matters in distributed systems. A low-traffic instance and a high-traffic instance can report very different quantiles, and combining them by averaging or selecting the “worst” value will usually misrepresent the true fleet-wide latency or size distribution.

For that reason, summaries are a good fit for per-instance visibility, but less suitable when you need consistent aggregation across replicas, clusters or autoscaled groups.

When to use a summary metric

Use a summary when local quantiles are the main requirement and the metric will be read primarily as a service-local signal. It is a strong choice when instrumentation happens close to the event and when the main consumer is the same component, team or alerting rule that owns that instance.

Use caution when the metric is intended for central reporting, capacity planning across many instances, or organisation-wide SLO calculations. In those cases, a histogram is usually the better fit because its bucketed observations can be aggregated before quantiles are derived.

In short, a summary trades global composability for immediate, local percentile visibility.

Related resources from NHI Mgmt Group

• What is the difference between an outcome metric and a control metric?
• How do you know if an identity metric is actually working?
• Why do AI governance programmes need a single readiness metric?
• How can organisations use a security assessment without turning it into a vanity metric?