If you have ever asked the question, “Is Redis slow or is it something else?”, you already understand why monitoring matters.
Redis is often blamed first when systems misbehave. In most cases, Redis is not the real problem. The real issue is that the right signals were not monitored early enough.
Monitoring Redis is not about collecting every metric it exposes. Redis exposes many metrics. Effective monitoring is about knowing which numbers provide useful insight before users start complaining.
Most production outages involving Redis show warning signs. These signs usually go unnoticed because teams focus on the wrong dashboards.
The Goal of Redis Monitoring
The goal is not to prove that Redis is fast. It already is.
The real goal is to confidently answer the following questions:
Is Redis healthy right now?
Is Redis becoming unhealthy?
Will Redis fail soon if nothing changes?
If your monitoring setup cannot answer these questions, it is mostly noise.
Start With the Basics: Is Redis Alive and Responsive
This may sound obvious, but it is critical.
You need clear visibility into:
Whether Redis is reachable
Whether it is responding to commands
Whether latency is stable
A Redis instance that is running but responding slowly is already a problem. Many teams only alert on complete outages. By the time Redis is fully down, users have already experienced issues.
Latency is often the first indicator that something is wrong.
Latency: The Canary Metric
Latency reveals more about Redis health than almost any other metric.
Normal Redis latency is typically sub-millisecond. When latency consistently rises into multiple milliseconds, something is happening under the hood.
Common causes include:
The key is not to rely on average latency alone. Averages can hide real problems.
You should closely monitor:
Spikes in tail latency often appear before throughput drops or error rates increase.
Throughput: Commands Per Second
Commands per second help you understand the load on Redis.
On its own, this metric is neither good nor bad. High throughput is fine if latency remains low. Low throughput is not acceptable if latency is high.
What matters is the relationship between throughput and latency.
If throughput is stable and latency rises, Redis is struggling.
If throughput increases and latency remains flat, Redis is healthy.
Sudden drops in throughput combined with rising latency usually indicate that Redis is overwhelmed or blocked.
Memory Usage: Where Things Get Subtle
Memory usage is where many Redis systems slowly drift toward failure.
Most teams start by monitoring used memory. While necessary, this alone is not enough.
You should also monitor:
Memory fragmentation matters because Redis frequently allocates and frees memory. A fragmentation ratio significantly greater than one indicates that Redis is holding memory it cannot reuse efficiently. This can lead to out-of-memory errors even when reported memory usage appears acceptable.
Evicted keys indicate memory pressure. Evictions are not inherently bad in a caching system, but they are a serious concern if they occur unexpectedly.
If eviction rates suddenly increase, something has changed. Traffic may have increased, data size may have grown, or the TTL strategy may be incorrect.
Expired keys per second is generally a healthy metric. If this value is consistently near zero in a cache-heavy system, keys are likely missing TTLs.
Key Count: The Slow Creep Metric
Key count seems uninteresting until it is not.
In a well-designed cache, key count should fluctuate within a predictable range. It should not grow indefinitely.
If key count only increases and never decreases, you are likely leaking keys.
Common causes include:
Key count growth is slow and easy to ignore. Eventually, Redis reaches memory limits and eviction behavior becomes unpredictable.
Monitoring key count trends over time is one of the simplest ways to detect poor cache design early.
Evictions: Normal or a Warning Sign
Evictions occur when Redis removes keys to make room for new ones.
In some systems, evictions are expected and healthy. In others, they signal serious problems.
Evictions are generally acceptable when:
Redis is used strictly as a cache
TTLs are set consistently
The eviction policy matches access patterns
Evictions are a red flag when:
Redis stores critical application state
TTLs are inconsistent or missing
Eviction rates spike unexpectedly
Any sudden change in eviction behavior should be investigated immediately.
Persistence Metrics: When Disk Affects Memory
If Redis persistence is enabled, disk behavior becomes important.
For RDB persistence, monitor:
Long fork times can briefly block Redis and increase latency, especially with large datasets.
For AOF persistence, monitor:
AOF file size
AOF rewrite duration
AOF rewrite failures
AOF rewrite failures are particularly dangerous because they can silently compromise durability if not detected.
Hybrid persistence reduces some risks but does not eliminate the need for monitoring.
CPU Usage: Redis Is Single-Threaded by Design
Redis executes commands on a single main thread. This design improves predictability but makes CPU saturation critical.
If Redis CPU usage consistently approaches a full core, latency will increase.
Common causes include:
Heavy Lua scripts
Operations on very large keys
Slow commands such as KEYS
High write volume combined with AOF fsync
Redis is fast, but CPU resources are still finite.
Slow Log: The Most Underused Tool
Redis includes a built-in slow log, yet it is often overlooked.
The slow log records commands that exceed a configured execution threshold.
This is where you uncover:
Accidental O(N) operations
Large payload handling issues
Poor client behavior
Unexpected blocking commands
Slow logs frequently explain issues that raw metrics cannot. Reviewing them should be part of regular operational hygiene.
Connection Metrics: Hidden Load
Connection-related metrics are often underestimated.
You should monitor:
Connected clients
Blocked clients
A sudden increase in connected clients may indicate connection leaks. Blocked clients often point to long-running commands or contention.
Blocked clients are especially dangerous, as they frequently precede timeouts and cascading failures.
Network Metrics: Redis Is Not Always the Culprit
High Redis latency is sometimes caused by network issues rather than Redis itself.
Examples include:
Packet loss
Network saturation
Cross-region traffic
If Redis is accessed remotely, network metrics must be correlated with Redis metrics before assigning blame.
Alerts That Actually Make Sense
Effective alerts are boring and actionable.
Useful alerts include:
Sustained latency above baseline
Unexpected increases in eviction rate
Memory usage approaching configured limits
AOF rewrite failures
Redis becoming unreachable
Poor alerts include:
Alerts should indicate when action is required, not when to panic.
Dashboards vs Understanding
Dashboards are only as valuable as the questions they answer.
A dashboard displaying fifty metrics is often worse than one showing ten well-understood metrics.
Every monitored metric should serve a clear purpose. If you cannot explain why a metric matters, it should be removed.
The Most Common Monitoring Mistake
The biggest mistake teams make is assuming Redis monitoring is a set-and-forget task.
Traffic patterns change.
Data characteristics change.
Usage patterns evolve.
Monitoring thresholds that made sense months ago may no longer be valid.
Redis dashboards should be reviewed and adjusted regularly as the system evolves.
A Simple Mental Model That Works
When monitoring Redis, think in terms of pressure:
Memory pressure
CPU pressure
Latency pressure
Redis failures rarely happen instantly. Pressure builds over time, and metrics tell that story if you are paying attention.
Final Thoughts
Effective Redis monitoring does not require exotic tools. It requires clarity.
Know what healthy looks like
Know what unhealthy looks like
Understand the direction metrics are moving
When Redis is monitored properly, issues are detected early and resolved calmly.
When monitoring is poor, small problems escalate into large, seemingly random incidents.
Redis is predictable. Your monitoring strategy should be as well.
Join the conversation! Your thoughts help the community grow.