At a glance
Query Latency p50 (ms) is the median round-trip time for read operations on the selected MongoDB deployment, sampled over a rolling 5-minute window. Half of all reads complete faster than this number and half complete slower, so it is the “typical” experience a query gets, not the worst case. Watch it as the baseline against which p95 and p99 spikes are judged: a healthy p50 with a runaway tail points at a few bad queries, whereas a rising p50 points at a systemic slowdown (cache pressure, slow disk, or contention).
What it tracks
The card reports the median read latency for the deployment over the selected period. It is derived from the samelatencies.reads operation-latency histogram that serverStatus exposes for the p95 card, but reads at the 50th percentile rather than the tail. Because it is the median, it ignores the handful of pathological slow ops and tells you what a normal read costs right now. A stable p50 (for an OLTP workload, often in the low single-digit to low-double-digit milliseconds for cache-resident data) is the expected steady state; sustained upward drift across a 5-minute window is the signal that the working set has outgrown the WiredTiger cache or that disk latency has crept in. This card carries no alert threshold of its own; it is the context line for the alerting p95 and p99 cards.
Reconciling against the source
Confirm against MongoDB’s own tooling by runningdb.serverStatus().opLatencies.reads (or db.runCommand({serverStatus: 1}).opLatencies) on the deployment and dividing latency by ops for the cumulative average, or use mongostat and the Atlas Metrics “Read Latency” chart for the live percentile view. Atlas reports percentiles directly; a self-hosted node exposes cumulative counters, so divide deltas between two samples to recover a windowed figure that matches the Nerve Centre’s 5-minute reading.