Gauge (SQL)
A Gauge panel is a single-number readout — not a chart over a range of categories or time, but one value read against color-coded thresholds. Use it for a KPI you want to check at a glance: an average order value, an error rate, anything with a “good/warning/bad” zone.
Query convention
SELECT count() AS valueFROM chomper.eventsWHERE timestamp >= parseDateTimeBestEffort({from:String}) AND timestamp <= parseDateTimeBestEffort({to:String})
One column aliased value, one or more rows. A reducer — Last received / Maximum / Minimum / Average — collapses however many rows come back into the single number actually shown. If your query already returns one pre-aggregated row, every reducer agrees; the choice only matters once a query returns several rows (say, one per day) and you want the latest, the worst, or the typical one of them.
Thresholds and display styles
Instead of a single color, a gauge takes an ordered list of thresholds — “from this value upward, use this color” — the same mental model as Grafana's. Three display styles share the same threshold math:
Gauge style — “Avg receipt total,” average reducer, green→amber→rose thresholds at 0 / 4,000 / 8,000.
Bar (horizontal) style — “Complaints per 100 sales,” thresholds at 0 / 50 / 80.
A gauge also has optional extras: a needle, min/max scale labels, and a plain “Show value” toggle for when the shape alone is enough — useful in a dense row of several gauges side by side.
Example: Avg receipt total — reducing per-row values
SELECT JSONExtractFloat(metadata, 'receipt_total') AS valueFROM chomper.eventsWHERE event_class = 'sale' AND timestamp >= parseDateTimeBestEffort({from:String}) AND timestamp <= parseDateTimeBestEffort({to:String})ORDER BY timestamp
This query does not pre-aggregate — it returns one value per matching sale, and the panel's Average reducer collapses them client-side. The threshold breakpoints (0 / 4,000 / 8,000) are calibrated to where this data actually lands, not round numbers picked for looks — worth doing for your own gauges too, since an uncalibrated threshold either never leaves green or sits permanently in red regardless of what the data does.
Example: Complaints per 100 sales — a single pre-aggregated row
SELECT if( countIf(event_class = 'sale') = 0, 0, 100 * countIf(event_class IN ('call', 'chat', 'email') AND is_negative = 1) / countIf(event_class = 'sale')) AS valueFROM chomper.eventsWHERE timestamp >= parseDateTimeBestEffort({from:String}) AND timestamp <= parseDateTimeBestEffort({to:String})
The opposite pattern: this query already returns exactly one row, so the reducer is along for the ride rather than doing real work. It counts complaints against sales volume — a directly business-meaningful ratio (“for every 100 sales, how many complaints came in”) — and the if(... = 0, 0, ...) guard avoids a division-by-zero error on a time range with no sales at all. This panel has no drill-down configured: every threshold zone would click through to the exact same set of complaints regardless of which zone was clicked, since the ratio itself isn't a per-row field a click could narrow. That's worth applying generally — only wire a drill-down where the clicked zone genuinely narrows which rows you'd see.
Drilling down into a threshold zone
Where a drill-down is configured, clicking a zone (or hovering it, for its range) runs the query with {thresholdFrom}/{thresholdTo} bound to that zone's boundaries.
Last updated 9 July 2026