Apply Prometheus counter rate before aggregating instances

Summing counters first can conceal the reset behavior needed for an accurate rate.

Source facts

Prometheus documents that rate should be applied before aggregation or aggregation-over-time functions. Rate detects counter resets in each input series; aggregating first can prevent that detection when a target restarts. The function is intended for counters rather than arbitrary gauges. Expression order therefore affects the meaning of the resulting operational signal.

Source: Prometheus documentation — Query functions.

Applicability

Review PromQL counter rate calculation before aggregate functions are applied.

DSE recommendation

DSE recommends preserving the original per-instance counter series through rate calculation and aggregating only afterward at the required service level. Review copied dashboard expressions for the order of operations, especially where instances restart independently. Keep metric type and units with the query so a gauge is not accidentally treated as a counter. Choose a window consistent with the scrape interval and the question being answered, and explain the aggregation labels retained in the output.

Verification

In a test dataset, compare the intended expression with one that aggregates raw counters first while a single instance resets. Inspect the per-instance rate and final aggregate against the known test behavior. Confirm the production query retains the required service boundaries without relying on a superficially similar but semantically different expression. Retain the raw per-instance test samples and reset time with both expression results. Ask the metric owner to explain the observed difference and approve the exact aggregation labels before changing a shared dashboard or recording rule.

Official reference

Prometheus documentation — Query functions. Reviewed October 20, 2026.