api_request_latency_ms synthetic 7-day trace, 1-minute resolution

Sampling and the shape of your histogram

Same underlying metric, same "more data is better" instinct. Drag the window below to change how much of the week you sample from, and where — then watch what happens to the distribution on the right.

Full trace — 7 dayshighlighted band = current sampling window

overnight trough
daytime rise / fall
evening incident spike

Sampling windowthis is the "zoom" — what you'd change in a metrics explorer

Window lengthhow much time you include
—
Window positionwhich part of the week
—

Selected window

Distribution of sampled values

samples (n)—
mean—
std. deviation—
skewness—
— Adjust the sliders above to sample the metric.

More samples don't always mean "more normal." A 7-day window has ~10,000 points — far more than a 2-hour window — but it's almost always the worse choice here. It repeatedly crosses the same daily rise and fall, so the histogram just becomes a smoother version of the same two-humped shape. That's not noise you can average away; it's the actual shape of a metric with a daily cycle.

The 15-minute window fails for the opposite reason: too few points to say anything about the shape at all. The useful "middle" is a window long enough to gather a reasonable sample, sitting inside a stretch of time where the underlying process isn't shifting gears — not asleep at 3 a.m., not mid-ramp at 7 a.m., not straddling an incident spike.

In a monitoring console this is exactly why a wider time range or a coarser alignment period can make a chart look worse, not better — and why the fix is usually picking a more representative slice, not adding more of it.