Redis LATENCY Report Analyzer

Paste the output of redis-cli LATENCY LATEST. Before reading it, know this: the latency monitor is disabled by default, so an empty report means either no spikes or nothing recorded, and those look identical.

Paste below, or drop a file anywhere on this panel

Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.

The answer appears here

Paste on the left and press Analyze. Nothing leaves this tab.

Examples

Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.

A 1.5 second command

One thread, so this is dead time for every other client

1) 1) "command"
   2) (integer) 1699000000
   3) (integer) 250
   4) (integer) 1500

Nothing recorded

The report is empty, which usually means the monitor was never switched on

(empty array)

Common mistakes

These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.

  1. Reading an empty report as a healthy server

    The monitor is disabled by default, so an empty report is also what a server with constant stalls produces.

    Instead:CONFIG SET latency-monitor-threshold 100 first.

  2. Setting the threshold at runtime only

    CONFIG SET is lost on restart, so the monitoring quietly stops after the next one.

    Instead:Put it in redis.conf as well.

  3. Treating a fork event as something to tune

    Fork cost scales with mapped memory and is inherent to saving. There is no setting that removes it.

    Instead:Move saves to a replica, or reduce memory per instance.

  4. Using LATENCY to find which command was slow

    It names the subsystem, not the command.

    Instead:Use SLOWLOG for the specific command and its arguments.

What each latency event is actually telling you

Redis names the subsystem that stalled rather than the command that suffered, which is more useful once the names are familiar.

An empty report is ambiguous, and that is the first thing to resolve

latency-monitor-threshold defaults to 0, which means the monitor records nothing at all. An empty LATENCY LATEST is therefore consistent with a perfectly healthy server and with a server that has been stalling for months. Set the threshold before concluding anything.

fork is the cost of a background save

Redis forks for BGSAVE and for AOF rewrite, and the pause scales with how much memory the process has mapped. On virtualised hardware it is often several times worse than on bare metal. Moving saves to a replica removes it from the primary entirely.

command means an O(N) call over something large

A command event is dead time for every other client, because there is one thread. It is almost always KEYS, a full HGETALL or SMEMBERS, or a wide range query. SLOWLOG names the specific command; LATENCY only says that one was slow.

expire-cycle and eviction-cycle are capacity signals

The first means a large number of keys expired at once, which is fixed by adding jitter to TTLs so they do not land in the same second. The second means the instance is at maxmemory and doing eviction work constantly, which is a sizing problem rather than a tuning one.

What this cannot see

Only events above the threshold, only since the last LATENCY RESET, and only on this node. Latency the client experienced from network or from its own connection pool never appears here at all.