Redis Monitoring: 6 Metrics That Decide If Your Cache Is Helping

Most stacks have a Redis instance that started life as "just a cache." Then someone stored sessions in it. Then rate-limit counters, then a job queue, then a leaderboard. Nobody declared a migration, but at some point it quietly stopped being a cache and became a primary datastore — one with no schema, no query planner, and, in most shops, no real monitoring beyond "the pod is green."

That's why Redis monitoring is a different problem from checking that a pod is up. Redis fails gradually and then suddenly: hit ratio erodes for weeks, fragmentation creeps up, and the visible incident — a latency spike, an eviction storm, an out-of-memory error at peak traffic — is only the last frame of the film. Monitoring Redis well means watching six specific signals, knowing what "bad" looks like for each, and having one command ready to check it. This guide covers exactly that. Every check runs from redis-cli in seconds.

This is part one of a three-part series. Part two is a hands-on Redis performance audit using only native tools; part three covers automating continuous Redis monitoring with an AI agent.

1. Cache hit ratio

What it is. The fraction of reads Redis answers from memory instead of returning a miss that your application then serves from the database. It's not reported directly — you compute it from two counters in INFO stats:

redis-cli INFO stats | grep -E 'keyspace_hits|keyspace_misses'

Hit ratio = keyspace_hits / (keyspace_hits + keyspace_misses). Note these counters are cumulative since the last restart, so for a live picture, sample twice a few minutes apart and diff.

What bad looks like. For a true cache workload, sustained hit ratios below roughly 90% deserve a look, and below 80% something is structurally wrong: TTLs shorter than the reuse interval, cache keys that include a timestamp or UUID so they never repeat, or a working set larger than maxmemory so useful keys get evicted before they're read again.

Typical impact. Every point of hit ratio you lose is load transferred to the database behind Redis. Dropping from 95% to 85% triples the miss traffic — the database sees 3x the cache-miss queries, and p99 latency on those requests goes from sub-millisecond to whatever your database does under pressure.

2. Memory fragmentation ratio

What it is. mem_fragmentation_ratio in INFO memory is the ratio between the memory the OS has given the Redis process (RSS) and the memory Redis thinks it's using (used_memory). Churn-heavy workloads — lots of writes, deletes, and varying value sizes — leave the allocator holding pages it can't return.

redis-cli INFO memory | grep -E 'used_memory_human|used_memory_rss_human|mem_fragmentation_ratio'

What bad looks like. A ratio between 1.0 and about 1.4 is healthy. Above 1.5, a meaningful share of your RAM is allocator overhead — at 2.0, a "4 GB" Redis is occupying 8 GB of real memory. Below 1.0 is worse news of a different kind: the OS has swapped part of Redis to disk, and any command touching a swapped page will stall the entire single-threaded event loop.

Typical impact. Fragmentation is invisible until capacity math fails: the instance OOMs or triggers evictions while used_memory still looks fine. On managed platforms it commonly forces a node-size upgrade one tier early — you pay for RAM the allocator wastes. Modern Redis can defragment live via activedefrag yes; run redis-cli MEMORY DOCTOR for the allocator's own diagnosis.

3. Evictions and expirations under maxmemory

What it is. When Redis reaches maxmemory, the configured maxmemory-policy decides what happens: noeviction makes writes fail with an OOM error, while the allkeys-* and volatile-* policies silently delete keys to make room. Watch the counters:

redis-cli INFO stats | grep -E 'evicted_keys|expired_keys'
redis-cli CONFIG GET maxmemory-policy

What bad looks like. Two failure modes, opposite symptoms. With noeviction (the default in open-source Redis), a full instance starts throwing OOM command not allowed when used memory > 'maxmemory' — an outage for anything that writes. With an allkeys-* policy, a full instance keeps working while deleting data: fine for pure cache entries, catastrophic when the same instance also holds sessions or queue items, because "cache eviction" becomes "users randomly logged out." A steadily climbing evicted_keys means the working set no longer fits; a near-zero expired_keys on a cache workload means keys have no TTLs at all and only eviction pressure ever removes them.

Typical impact. Eviction storms are self-amplifying: evictions lower the hit ratio, misses trigger recomputation and re-writes, which trigger more evictions. Teams typically discover the mixed-workload problem during their first traffic spike, as a spike in support tickets rather than a metric.

4. Slow commands: KEYS and the O(N) family

What it is. Redis executes commands on a single thread. One KEYS * against a few million keys, an HGETALL on a giant hash, SMEMBERS on a huge set, or LRANGE mylist 0 -1 blocks every other client until it finishes. The slow log records anything exceeding slowlog-log-slower-than (default 10,000 microseconds):

redis-cli SLOWLOG GET 10

For intermittent stalls that aren't slow commands — forks for persistence, transparent huge pages, disk I/O — enable latency monitoring (CONFIG SET latency-monitor-threshold 100) and ask Redis to diagnose itself with LATENCY DOCTOR.

What bad looks like. Any appearance of KEYS in the slow log of a production instance (use SCAN instead, always). Repeated entries for the same command pattern at 50 ms and up. A slow log that's empty not because the instance is healthy but because nobody lowered the threshold from the default.

Typical impact. A single 200 ms command is a 200 ms latency spike for every concurrently connected client — this is the most common source of mysterious p99 spikes that "don't correlate with anything" on the CPU or network graphs.

5. Big keys and hot keys

What it is. Two different concentration problems. A big key is one enormous value — a 500 MB hash, a list with two million entries — that makes every operation touching it expensive and makes eviction or deletion of that one key a stall event. A hot key is a small key receiving a disproportionate share of traffic, pinning one shard or one CPU core while the rest of the cluster idles. Find them with the built-in scanners:

redis-cli --bigkeys
redis-cli --hotkeys   # requires an LFU maxmemory-policy (allkeys-lfu or volatile-lfu)

Both use incremental SCAN under the hood, so they're production-safe, if not free. For a specific suspect, redis-cli MEMORY USAGE keyname reports the exact bytes.

What bad looks like. Any single key holding more than a few MB, or a collection with hundreds of thousands of elements. For hot keys: one key absorbing an order of magnitude more ops than its peers — the classic case is a shared counter or a "front page" cache entry that every request reads.

Typical impact. Big keys turn routine operations into incidents — a DEL on a multi-GB key can block for seconds (use UNLINK, which frees memory in the background). Hot keys cap your cluster's throughput at the capacity of one node, which is why "we sharded Redis and nothing got faster" is such a common story.

6. Replication lag

What it is. If you run replicas — for read scaling or failover — the replica applies the primary's write stream asynchronously. The gap is measured in bytes of replication offset:

redis-cli INFO replication

On the primary, compare master_repl_offset with the offset reported in each slaveN: line; the difference is the lag. Also check master_link_status:up on the replica.

What bad looks like. An offset gap that grows instead of oscillating near zero, or repeated full resynchronizations (sync_full climbing in INFO stats) — usually a sign the replication backlog (repl-backlog-size, default 1 MB) is too small for your write rate, so every brief network blip forces a full copy of the dataset.

Typical impact. Stale reads from replicas — a user writes on the primary and reads their old data from a lagging replica. Worse, a failover to a lagging replica silently loses every write inside the gap. Repeated full syncs also hammer the primary: each one forks the process and snapshots the dataset.

The pattern behind all six

Notice what these metrics have in common: none of them page anyone at the moment they go bad. Hit ratio decays over weeks. Fragmentation accumulates over months. A big key grows one LPUSH at a time. The KEYS call ships in an innocuous PR. Then a traffic spike arrives and all of the slack is gone at once.

Point-in-time checks — the kind you just learned — catch these only if someone runs them regularly, and the counters reset on every restart, so history evaporates exactly when you need it for a post-incident timeline. The realistic first step is a disciplined manual baseline: part two of this series walks through a full Redis performance audit with nothing but redis-cli and the tools Redis ships in the box — INFO, SLOWLOG, LATENCY, MEMORY, --bigkeys — and how to choose the right maxmemory-policy for your workload.

Watch these six continuously

Every check in this guide can run on autopilot. Tony, CloudThinker's database agent, connects to Redis read-only and tracks hit ratio, fragmentation, evictions, slow commands, big keys, and replication lag continuously — flagging the drift the week it starts, not the quarter it becomes an incident, with any remediation gated behind your approval. Part three of this series shows how it works. Try CloudThinker free — 100 premium credits, no card required.