Metrics query results change unexpectedly when adjusting granularity
Last updated: June 12, 2026
Why this happens
Some metrics represent delta values (bytes per interval, requests per interval) but are classified as a gauge in Honeycomb based on how the source exports them. This is common with vendors like Confluent Cloud, which export delta counter metrics as Prometheus gauge type.
When a metric is classified as gauge, Honeycomb applies LAST temporal aggregation by default. LAST keeps only the most recent data point per timeseries per time bucket, discarding the rest. For a delta metric, this means coarser granularity discards more data points per bucket, resulting in lower or zero totals.
You can check whether this applies to your metric by hovering over the metric name in the query builder. If the tooltip shows "Uses SUM(LAST(...)) by default" and the metric represents a rate or delta count rather than a point-in-time measurement like CPU or memory, the default temporal aggregation is not the right fit.
How to fix it
Override the temporal aggregation using a calculated field with SUMMARIZE($your_metric_name). SUMMARIZE sums all data points within each time bucket instead of keeping only the last one, giving you consistent totals at any granularity.
For more on temporal aggregation, see Applying Temporal Aggregation Functions.