{
  "id": "latency-monitor",
  "title": "Redis latency monitoring",
  "url": "https://redis.io/docs/latest/operate/oss_and_stack/management/optimization/latency-monitor/",
  "summary": "Discovering slow server events in Redis",
  "tags": [
    "docs",
    "operate",
    "stack",
    "oss"
  ],
  "last_updated": "2026-04-01T08:10:08-05:00",
  "page_type": "content",
  "content_hash": "e970191df53dd083203e24af587da1dba0d904098dc49e1147e9f9101c8b65ed",
  "sections": [
    {
      "id": "overview",
      "title": "Overview",
      "role": "overview",
      "text": "Redis is often used for demanding use cases, where it\nserves a large number of queries per second per instance, but also has strict latency requirements for the average response\ntime and the worst-case latency.\n\nWhile Redis is an in-memory system, it deals with the operating system in\ndifferent ways, for example, in the context of persisting to disk.\nMoreover Redis implements a rich set of commands. Certain commands\nare fast and run in constant or logarithmic time. Other commands are slower\nO(N) commands that can cause latency spikes.\n\nFinally, Redis is single threaded. This is usually an advantage\nfrom the point of view of the amount of work it can perform per core, and in\nthe latency figures it is able to provide. However, it poses\na challenge for latency, since the single\nthread must be able to perform certain tasks incrementally, for\nexample key expiration, in a way that does not impact the other clients\nthat are served.\n\nFor all these reasons, Redis 2.8.13 introduced a new feature called\n**Latency Monitoring**, that helps the user to check and troubleshoot possible\nlatency problems. Latency monitoring is composed of the following conceptual\nparts:\n\n* Latency hooks that sample different latency-sensitive code paths.\n* Time series recording of latency spikes, split by different events.\n* Reporting engine to fetch raw data from the time series.\n* Analysis engine to provide human-readable reports and hints according to the measurements.\n\nThe rest of this document covers the latency monitoring subsystem\ndetails. For more information about the general topic of Redis\nand latency, see [Redis latency problems troubleshooting]()."
    },
    {
      "id": "events-and-time-series",
      "title": "Events and time series",
      "role": "content",
      "text": "Different monitored code paths have different names and are called *events*.\nFor example, `command` is an event that measures latency spikes of possibly slow\ncommand executions, while `fast-command` is the event name for the monitoring\nof the O(1) and O(log N) commands. Other events are less generic and monitor\nspecific operations performed by Redis. For example, the `fork` event\nonly monitors the time taken by Redis to execute the `fork(2)` system call.\n\nA latency spike is an event that takes more time to run than the configured latency\nthreshold. There is a separate time series associated with every monitored\nevent. This is how the time series work:\n\n* Every time a latency spike happens, it is logged in the appropriate time series.\n* Every time series is composed of 160 elements.\n* Each element is a pair made of a Unix timestamp of the time the latency spike was measured and the number of milliseconds the event took to execute.\n* Latency spikes for the same event that occur in the same second are merged by taking the maximum latency. Even if continuous latency spikes are measured for a given event, which could happen with a low threshold, at least 160 seconds of history are available.\n* Records the all-time maximum latency for every element.\n\nThe framework monitors and logs latency spikes in the execution time of these events:\n\n* `command`: regular commands.\n* `fast-command`: O(1) and O(log N) commands.\n* `fork`: the `fork(2)` system call.\n* `rdb-unlink-temp-file`: the `unlink(2)` system call.\n* `aof-fsync-always`: the `fsync(2)` system call when invoked by the `appendfsync allways` policy.\n* `aof-write`: writing to the AOF - a catchall event for `write(2)` system calls.\n* `aof-write-pending-fsync`: the `write(2)` system call when there is a pending fsync.\n* `aof-write-active-child`: the `write(2)` system call when there are active child processes.\n* `aof-write-alone`: the `write(2)` system call when no pending fsync and no active child process.\n* `aof-fstat`: the `fstat(2)` system call.\n* `aof-rename`: the `rename(2)` system call for renaming the temporary file after completing [`BGREWRITEAOF`](/commands/bgrewriteaof).\n* `aof-rewrite-diff-write`: writing the differences accumulated while performing [`BGREWRITEAOF`](/commands/bgrewriteaof).\n* `active-defrag-cycle`: the active defragmentation cycle.\n* `expire-cycle`: the expiration cycle.\n* `eviction-cycle`: the eviction cycle.\n* `eviction-del`: deletes during the eviction cycle."
    },
    {
      "id": "how-to-enable-latency-monitoring",
      "title": "How to enable latency monitoring",
      "role": "content",
      "text": "What is high latency for one use case may not be considered high latency for another. Some applications may require that all queries be served in less than 1 millisecond. For other applications, it may be acceptable for a small amount of clients to experience a 2 second latency on occasion.\n\nThe first step to enable the latency monitor is to set a **latency threshold** in milliseconds. Only events that take longer than the specified threshold will be logged as latency spikes. The user should set the threshold according to their needs. For example, if the application requires a maximum acceptable latency of 100 milliseconds, the threshold should be set to log all the events blocking the server for a time equal or greater to 100 milliseconds.\n\nEnable the latency monitor at runtime in a production server\nwith the following command:\n\n    CONFIG SET latency-monitor-threshold 100\n\nMonitoring is turned off by default (threshold set to 0), even if the actual cost of latency monitoring is near zero. While the memory requirements of latency monitoring are very small, there is no good reason to raise the baseline memory usage of a Redis instance that is working well."
    },
    {
      "id": "report-information-with-the-latency-command",
      "title": "Report information with the LATENCY command",
      "role": "content",
      "text": "The user interface to the latency monitoring subsystem is the [`LATENCY`](/commands/latency) command.\nLike many other Redis commands, [`LATENCY`](/commands/latency) accepts subcommands that modify its behavior. These subcommands are:\n\n* [`LATENCY LATEST`](/commands/latency-latest) - returns the latest latency samples for all events.\n* [`LATENCY HISTORY`](/commands/latency-history) - returns latency time series for a given event.\n* [`LATENCY RESET`](/commands/latency-reset) - resets latency time series data for one or more events.\n* [`LATENCY GRAPH`](/commands/latency-graph) - renders an ASCII-art graph of an event's latency samples.\n* [`LATENCY DOCTOR`](/commands/latency-doctor) - replies with a human-readable latency analysis report.\n\nRefer to each subcommand's documentation page for further information."
    }
  ],
  "examples": []
}