At a glance
Query Latency p50 (ms) is the median query duration in milliseconds: half of all queries finish faster, half slower. It tells a platform team how a typical query feels on the ClickHouse instance right now. Read it alongside the tail percentiles (p95 and p99): a flat p50 with a rising p95 means a slow minority, while a rising p50 means the whole instance has slowed down.
What it tracks
Query Latency p50 (ms) for the selected period is the 50th-percentile ofquery_duration_ms over completed queries in a rolling window, drawn from system.query_log. It is server-side wall-clock time per query, not network or client render time, and it covers all completed query types (SELECT, INSERT, DDL). Because it is the median, it is robust to a handful of slow outliers: one runaway query barely moves p50, which is exactly why it is the right metric for “how does a normal query feel?” rather than “how bad is the worst case?”. The card has no alert threshold of its own; it is a context metric that you read against the tail-latency cards and Queries per Second (live) to tell genuine load from a slow-query problem. A rising p50 is the signal that the instance as a whole is under pressure (load, contention, or a stall), not just a slow subset of queries.
Reconciling against the source
Reproduce the headline directly in ClickHouse withSELECT quantile(0.5)(query_duration_ms) FROM system.query_log WHERE type = 'QueryFinish' AND event_time >= now() - 300 (use quantileExact(0.5) for an exact, slower figure). On ClickHouse Cloud the Metrics tab plots latency percentiles per service. Small differences come from approximate-vs-exact quantiles, log sampling (log_queries_probability below 1), and the sliding-window boundary.