# Histogram and distribution > The viewer needs the shape of a population, not a summary statistic of it. - Canonical: https://patterns.konigi.com/dashboards/histogram - Group: Visual representation - Level: implementation - Status: published - Updated: September 10, 2026 - Also called: distribution chart, bucketed bar --- ## Problem The average is 240ms. That single number is compatible with every request taking 240ms, and with half of them taking 80ms while the other half take 400ms. The viewer needs to know which world they are in. ## Solution Divide the range into buckets, count what falls in each, draw the counts as bars. The shape that comes out answers questions no summary statistic can: is this one population or two, is it symmetric or does it have a tail, is there a wall at some value where a timeout is truncating everything. Everything then depends on the buckets, and the buckets are usually somebody's default. Grafana's histogram panel defaults to a **Bucket count** of 30 when left empty, or you set **Bucket size** directly and leave it blank for automatic sizing at roughly 10% of the full range. There is also a **Bucket offset**, for when the first bucket shouldn't start at zero, which only does anything if it is greater than zero and smaller than the bucket size. Too few buckets and two humps merge into one. Too many and the shape dissolves into noise. Neither failure announces itself. On the storage side the same decision has already been made before the panel sees anything. Prometheus classic histograms are counted into fixed buckets chosen at instrumentation time, which is why the quantile estimates that come back out are bounded by bucket width and not by anything about the data. Native histograms change the arrangement by bucketing at a fixed relative resolution, so the resolution follows the magnitude instead of being guessed in advance. If you are choosing bucket boundaries by hand today, that is the thing worth knowing exists. Grafana also offers **Stacking** at Off, Normal or 100%, plus **Combine series** to merge everything into one distribution. Stacked histograms of several series are usually a mistake dressed as a feature: the reader has to compare areas that don't share a baseline. ## Use when The population is large enough to have a shape, and the question is about that shape. Latency, response size, session length, order value, anything where the tail or a second mode is the story. ## Don't use when The counts are small, where a histogram is a bar chart with a misleading name. Or when the change over time is the point, in which case the histogram is one frame of a film and a heatmap is the film. ## Trade-offs A histogram is a snapshot and discards time entirely, so a distribution that shifted badly an hour ago looks identical to one that has always been this shape. Bucket choice can manufacture or erase a second mode, and almost no dashboard exposes the bucket definition next to the chart. Comparing two histograms drawn at different scales is a trap readers fall into constantly, because the shapes are comparable-looking even when the axes are not. And a long tail forces a choice between clipping it, which hides the worst cases, and showing it, which squashes the body into the first two bars. ## Checklist - How many buckets, and who chose that number? - Would a different bucket count merge or split a mode that matters? - Are the bucket edges shown, and do any of them fall on a value people care about, like a timeout? - Is the x-axis linear when the data is skewed, and would a log axis show more? - Is the tail clipped, and does the chart say so? - Is the y-axis a count or a proportion, and does that match the neighbouring panels? - If two histograms sit side by side, do they share bucket edges and axis ranges? - Are these buckets computed at query time or fixed at instrumentation time? - Does the panel report the sample size? - Would a heatmap answer the viewer's actual question by adding time back? ## Compare **Grafana** exposes bucket count, size and offset as panel options, which is honest about the decision and also means two panels of the same metric can disagree about its shape with nothing on screen to explain why. **Prometheus** moves the argument upstream: classic histograms fix the buckets at instrumentation time, native histograms hold a relative resolution instead, so the same query returns a usefully different answer depending on which the service emits. **Honeycomb** keeps raw events rather than pre-aggregating, so a distribution is something you ask for at query time over whatever dimension you just thought of, rather than something you predicted a month ago. **Datadog** leans on distribution metrics with globally accurate percentiles, which trades the ability to see the shape for the ability to aggregate the summary correctly across hosts. ## Related Heatmap is this chart with time added back, and usually the better answer on an operational page. Percentile summary is the same data reduced to a few numbers, and inherits every bucket problem described here. Ratio and rate is the other normalisation people reach for when a raw count misleads. Stacked composition is what a histogram becomes when it is misused for several series at once. Data table is the fallback for readers who need the counts rather than the picture. ## Examples ### Grafana (Grafana Labs) The reference implementation for panel grids, template variables, and stat panels; most other tools are defined by how they differ from it. **Examples / Histogram** — captured September 10, 2026, Grafana Play (signed out; no version string exposed). analytical, medium density, dark theme, desktop-web. This page accidentally contains the cleanest demonstration of the bucket problem I have found in a shipped product. The panel top right is the source series, a line oscillating between 24 and 32. Directly under it, the same series on automatic buckets: roughly twenty-four bars, and it is plainly bimodal, with one hump around 27 and a taller one at 30.4. To the left of that, labelled "Force timeseries into bucket size=3", is the identical data at a bucket width of three. Four bars. One hump. The second mode has not been smoothed or de-emphasised, it is simply gone, and nothing about the chart indicates that a decision was made. Neither panel is wrong. One of them answers "is this one population or two" and the other cannot, and the only difference between them is a number in a field. Hotspots in this capture: - [Time series](https://patterns.konigi.com/dashboards/time-series) — The source series, before any bucketing. Two modes are not visible here either. - [Histogram and distribution](https://patterns.konigi.com/dashboards/histogram) *(this pattern)* — Automatic buckets on that series: clearly bimodal, humps at roughly 27 and 30.4. - [Histogram and distribution](https://patterns.konigi.com/dashboards/histogram) *(this pattern)* — The same data at bucket size 3. Four bars, one hump, and no sign that anything was lost. - [Histogram and distribution](https://patterns.konigi.com/dashboards/histogram) *(this pattern)* — A different series at the default count, showing a long left shoulder and a small second mode at 50.5. - [Sequential and diverging scales](https://patterns.konigi.com/dashboards/sequential-and-diverging-scales) — A gradient fill down each bar, encoding nothing. The height already carried the count. ### Kibana (Elastic) Query-first rather than panel-first: the search bar is the primary control and the charts are downstream of it, which inverts Grafana's arrangement. **Discover / filebeat logs** — captured September 10, 2026, Elastic demo environment (guest session; no version string exposed). analytical, dense density, light theme, desktop-web. Two panes: 315 fields down the left, 13,637 documents on the right, and a volume histogram over both. The left pane is the good half—it opens with a search box rather than a tree, which is the only sane way to navigate that many fields. The right pane is where it falls over. The documents table ships with two columns, a timestamp and "Summary", and Summary is every field on the record concatenated into one cell: agent.ephemeral_id, agent.id, agent.name, agent.type, agent.version, cloud.account.id, cloud.availability_zone, and on for three wrapped lines per row. It is technically complete and it cannot be scanned, so the first thing anyone does here is pick columns—which is to say the default view's job is to make you configure it. Underneath, the pager reads 100 rows per page across 137 pages, and the sort control sits above a table showing the first of them. Hotspots in this capture: - [Two-pane list and detail](https://patterns.konigi.com/dashboards/two-pane-list-detail) — Fields on the left, records on the right, both on screen at once. The oldest working shape for a queue there is. - [Detail on demand](https://patterns.konigi.com/dashboards/detail-on-demand) — An expander on every row. Inline rather than a side panel, so it pushes the rest of the list down. - [Data table](https://patterns.konigi.com/dashboards/data-table) — One column called Summary holding every field on the record. Complete, and unreadable at a glance. - [Search across panels](https://patterns.konigi.com/dashboards/search-across-panels) — 315 fields, so the sidebar opens with a filter box. Past a certain count a tree is a filing system nobody browses. - [Filter bar](https://patterns.konigi.com/dashboards/filter-bar) — A query language in the bar rather than chips. Powerful, and it hides what's applied from anyone who didn't type it. - [Time-range picker](https://patterns.konigi.com/dashboards/time-range-picker) — Relative by default, with the refresh control beside it rather than buried in a settings menu. - [Histogram and distribution](https://patterns.konigi.com/dashboards/histogram) *(this pattern)* — Volume over the window at a 30-second auto interval. The final bar is the bucket still filling, and it always reads low. ## Related patterns - [Heatmap](https://patterns.konigi.com/dashboards/heatmap) — Thousands of events per second can't be drawn as points; the viewer needs density. - [Percentile summary](https://patterns.konigi.com/dashboards/percentile-summary) — An average hides the slow requests users actually feel; the viewer needs the tail. - [Ratio and rate](https://patterns.konigi.com/dashboards/ratio-and-rate) — A raw count misleads; the viewer needs it normalized by a denominator they understand. - [Stacked composition](https://patterns.konigi.com/dashboards/stacked-composition) — A total is made of parts, and the viewer needs both the total and the mix over time. - [Data table](https://patterns.konigi.com/dashboards/data-table) — The viewer needs exact values for many items and wants to sort and scan them. ## Sources - [Grafana, Histogram panel](https://grafana.com/docs/grafana/latest/visualizations/panels-visualizations/visualizations/histogram/) - [Prometheus, Histograms and summaries](https://prometheus.io/docs/practices/histograms/) - [Prometheus, Native histograms](https://prometheus.io/docs/specs/native_histograms/) --- Screenshots on patterns.konigi.com are reproduced for commentary and criticism. Product names and marks belong to their owners.