Redis

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:

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:

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.

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:

Evictions are a red flag when:

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 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:

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:

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:

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:

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:

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:

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.

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.