Valkey hot key monitoring
A hot key isn't necessarily a large key - it's one receiving disproportionately high traffic. One overworked key can saturate a node while the rest of your cluster idles, and no amount of resharding will save you.
Why hot keys hurt
Single-core saturation
Operations on one key execute on one primary. A hot enough key saturates that node while the rest of the cluster idles.
Cluster imbalance
A key lives in exactly one slot on one shard. Hot keys defeat the whole point of sharding - no rebalancing helps, because the load is one key.
Latency for everyone else
Commands on the hot key queue ahead of everything else on that node, inflating latency for unrelated keys sharing the shard.
Cascading failures
If the hot key expires or is evicted, every client stampedes to rebuild it at once - the thundering-herd pattern.
How hot keys are detected
Valkey has no single "show me hot keys" command - every approach trades accuracy against overhead:
OBJECT FREQ / LFU
Accurate access-frequency counts, but requires an LFU eviction policy and per-key polling.
MONITOR sampling
Sees every command, but MONITOR is expensive to leave running against production. Usable for short, targeted capture windows.
Client-side instrumentation
Precise, but requires changing every client application.
SLOT-STATS (cluster, Valkey 8.0+)
Narrows the search to a hot slot cheaply - then key-level tracking identifies the culprit inside it.
What BetterDB automates
Continuous top-50 hot-key tracking with rank movement over time, on-demand MONITOR capture sessions for full traffic detail, and Key Analytics (Pro, free in early access) with type, TTL, and size distributions - so "hot" and "big" are measured separately, and a key climbing the ranks is visible before it becomes an incident.
FAQ
What is a hot key in Valkey or Redis?
A hot key is a key receiving disproportionately high access traffic relative to the rest of the keyspace. It is not necessarily a large key: a 100-byte counter read 50,000 times per second is hot; a 50 MB hash read once a day is big. The two problems have different symptoms and different fixes.
Why are hot keys a problem?
All operations on one key run on one node. A hot key saturates that node's CPU, inflates latency for other keys on the same shard, defeats cluster rebalancing (the load is a single key, which cannot be split across slots), and creates thundering-herd risk if it expires or is evicted.
How do I find hot keys in Valkey?
Options: OBJECT FREQ with an LFU eviction policy, short MONITOR capture windows, client-side instrumentation, or - in clusters on Valkey 8.0+ - CLUSTER SLOT-STATS to locate the hot slot first. BetterDB automates this: continuous top-50 hot-key tracking with rank movement over time, plus targeted MONITOR capture sessions when you need full traffic detail.
How do I fix a hot key?
Common remedies, in rough order: cache it client-side or in a local near-cache (accepting brief staleness), split it into multiple keys (sharded counters, per-segment hashes), serve reads from replicas where consistency allows, and protect expiry with jitter or a mutex to prevent stampedes. Which one applies depends on whether the traffic is reads or writes - which is why attribution matters.
What does BetterDB track beyond access frequency?
Rank movement over time (a key climbing the leaderboard is an early warning), and Key Analytics (Pro, free in early access) adds type, TTL, and size distributions from live sampling plus largest-keys-by-memory - so hot keys and big keys are distinguished instead of conflated.
Running a cluster? Find the hot slot first: cluster monitoring with SLOT-STATS →
See your top 50 keys in minutes
Ready to get started?
Start monitoring in minutes - no infrastructure to maintain. Team collaboration, agent-based monitoring for private databases, and more. Or self-host - open source core, zero lock-in.