At a glance
Command Latency p50 (us) is the median time, in microseconds, that the Redis server spends executing a command, measured server-side rather than including network round-trip. Healthy Redis sits comfortably in the tens-to-hundreds of microseconds at the median, so this card is your baseline “is the engine itself fast?” reading. It is the calm-weather companion to the p95 and p99 latency cards: when p50 itself starts climbing, the slowdown is broad rather than tail-only.
| What it tracks | The 50th-percentile (median) server-side command execution latency in microseconds (us). |
| Data source | LATENCY HISTORY (Redis 7+ per-event latency tracking) where available, or client-side sampling of command round-trips when the latency monitor is not enabled. |
| Time window | RT/5m (real-time, rolled over a trailing 5-minute window). |
| Alert trigger | None set. p50 is a baseline-watch metric, not a paging metric; the tail-latency cards carry the alert thresholds. |
| Roles | engineering, operations |
What it tracks
Redis is single-threaded for command execution, so the time the server spends inside a command is a direct, uncontended measure of how much work each command costs. The median (p50) tells you what a “typical” command looks like right now: aGET against a small string or a HGET against a modest hash should land in the low tens of microseconds. A rising p50 means the typical command is getting more expensive, which usually points at growing value sizes, an O(N) access pattern creeping into hot paths, or CPU contention on the host. Because p50 ignores the slow tail entirely, it is the cleanest signal that a regression is systemic rather than confined to a few pathological keys. Reported in microseconds because well-behaved Redis commands are sub-millisecond; surfacing this in us keeps the everyday range readable instead of rounding everything to “0ms”.
Reconciling against the source
Confirm the reading against Redis’s own latency tooling: runLATENCY HISTORY command (Redis 7+) or LATENCY LATEST for the per-event monitor, and redis-cli --latency / --latency-history for an end-to-end sampled view. On ElastiCache or MemoryDB, cross-check the SuccessfulReadRequestLatency and SuccessfulWriteRequestLatency CloudWatch metrics; note those are microsecond engine-side timings too, so they should track this card closely once the period and node are matched.