The Redis Latency Monitor for Systematic Performance Diagnosis

1. When the slowlog is not enough for diagnosis

The classic slowlog logs only individual commands whose execution time exceeds a configured threshold, making it ideal for identifying specific slow commands. Many latency problems in Redis, however, do not arise within command execution itself at all, but through internal operations such as a fork process for an RDB snapshot, deleting a large temporary file, or an expensive expiry cycle for keys with a TTL set, none of which show up in the slowlog at all.

The latency monitor closes exactly this gap by logging not only commands but various internal event classes along with their respective duration. That way, a latency spike that leaves no trace in the slowlog, because no single command took an unusually long time, can still be traced back to a concrete internal cause, which makes the decisive difference especially for sporadic, hard-to-reproduce problems.

2. Activation via latency-monitor-threshold

The latency monitor is activated through the latency-monitor-threshold configuration directive, which specifies in milliseconds the duration above which an event is recorded at all. A value of zero disables recording entirely, while a low value like one hundred milliseconds already captures moderate outliers without burdening the instance with an excessive number of logged events.

Unlike some other diagnostic tools, enabling the latency monitor itself carries negligible performance overhead, since it merely compares already measured internal timestamps against the threshold. For production environments, it is therefore recommended to keep the monitor permanently active rather than switching it on only for an acute problem, since sporadic events would otherwise go uncaptured exactly when they actually occur.

# Permanently enable the latency monitor with a 100ms threshold
redis-cli CONFIG SET latency-monitor-threshold 100
redis-cli CONFIG REWRITE

3. LATENCY HISTORY and the most important event classes

The LATENCY HISTORY command followed by an event name returns a list of past incidents of that class, each with its timestamp and measured duration. The most important event classes include command for commands that may sit below the slowlog threshold but are still relevant, fork for the duration of a fork operation during RDB or AOF persistence, expire-cycle for the periodic background process that removes expired keys, and rdb-unlink-temp-file for deleting a temporary snapshot file.

This breakdown by event class allows for a targeted investigation: frequent, growing fork events point to a dataset that has become too large for the configured persistence strategy, while recurring expire-cycle outliers rather point to a very large number of keys expiring simultaneously, a pattern that arises, for example, when many cache entries with an identical TTL were created at exactly the same time.

# Inspect the recent history of fork events
redis-cli LATENCY HISTORY fork
redis-cli LATENCY HISTORY expire-cycle

4. LATENCY LATEST for a quick overall overview

While LATENCY HISTORY focuses on a single event class, LATENCY LATEST returns a compact overview of every event class that has had at least one incident since the last reset, each with the time of the latest incident, its duration, and the maximum duration measured so far for that class.

This command is an excellent starting point for an acute latency investigation, since it shows in a single query which event classes are relevant at all before digging deeper into a specific class with LATENCY HISTORY. An empty result from LATENCY LATEST while application-side latency problems are simultaneously being observed is itself important diagnostic information, since it suggests the cause lies outside Redis, for example in the network or the application itself.

5. LATENCY DOCTOR as an automated analysis

LATENCY DOCTOR summarizes the recorded events in human-readable text and automatically maps noticeable patterns to known causes, such as a dataset that has grown too large for fork-based persistence or an unusually high number of keys expiring simultaneously. The output includes not just the raw observation but also concrete recommendations, phrased in plain language instead of a bare column of numbers.

It is important to treat LATENCY DOCTOR as a starting point rather than a final answer: the automated analysis reliably recognizes known, common patterns, but cannot always correctly separate unusual or overlapping causes. For more complex cases, manually inspecting LATENCY HISTORY for individual event classes remains indispensable to actually confirm the explanation LATENCY DOCTOR suggests.

redis-cli LATENCY DOCTOR

6. How it interacts with the slowlog

The latency monitor and the slowlog complement each other, since they represent different slices of the same reality: the slowlog answers the question of which specific command took an unusually long time, while the latency monitor answers the broader question of when and through what the instance overall was noticeably delayed, regardless of whether a single command or an internal background process was responsible.

In practice, a combined view pays off: if LATENCY LATEST shows a cluster of command events at a particular point in time, a subsequent look at SLOWLOG GET for the same period reveals the specific commands responsible, including their full arguments. Without this combined view, it would remain unclear either which command was at fault, or whether a command was even the cause at all rather than an internal process.

redis-cli LATENCY LATEST
redis-cli SLOWLOG GET 20

7. A practical diagnostic workflow for sporadic latency spikes

A proven workflow starts by making sure latency-monitor-threshold is permanently active, so events are actually captured as soon as they occur, instead of having to be laboriously reproduced only after the application side complains. Once a sporadic problem is reported, LATENCY LATEST provides a quick overview as the first step of which event classes are affected at all.

In the second step, LATENCY HISTORY for the most noticeable class delivers the time distribution of incidents, which can be cross-checked against external events such as deployment times, cron jobs, or backup windows. Only in the third step does LATENCY DOCTOR come in as a summarizing interpretation, followed by a comparison with the slowlog for the same period to determine whether specific application commands or internal Redis processes were the actual cause.

8. Typical causes behind common event classes

Frequent fork events with growing duration usually correlate directly with dataset size, since the fork operation has to copy more page table entries with larger data volumes, which can be narrowed down further with DEBUG OBJECT or MEMORY USAGE for individual suspiciously large keys. Frequent expire-cycle events, on the other hand, usually point to an unfortunate distribution of TTL values, where a very large number of keys expire simultaneously instead of being spread evenly over time.

Command events without a recognizable pattern in the slowlog that still show up in the latency monitor often point to operating-system-level causes, such as swapping due to insufficient memory or CPU throttling in a container environment with overly tight resource limits, causes that neither the slowlog nor the latency monitor names directly, but which are suggested by the sudden, seemingly unmotivated occurrence.

9. LATENCY RESET and integration into monitoring

The LATENCY RESET command clears the internally stored history of one or all event classes and is especially useful after a targeted optimization measure, such as adjusting TTL distributions or changing the persistence strategy, to measure again from a clean baseline whether the measure actually worked.

For lasting historization beyond a plain snapshot command, a regular, for example minutely, cron job that queries LATENCY LATEST and forwards the results into an external monitoring system like Prometheus is worthwhile, instead of relying exclusively on Redis's own limited, internally stored event count, which automatically discards the oldest entries once there are very many incidents.

# Reset the history of a specific event class
redis-cli LATENCY RESET fork
redis-cli LATENCY RESET

10. Summary

11. FAQ: Latency Monitor in Redis: Key Takeaways