Redis logging: runtime events, SLOWLOG, and latency diagnosis

Redis exposes several different diagnostic channels. Its runtime log records server events such as startup, persistence, and replication. SLOWLOG stores bounded, in-memory records of expensive commands. The latency monitor tracks internal event delays, while MONITOR streams command activity for short investigations. These channels answer different questions and need different collection methods.

Start with the runtime log and metrics for server health, then use slow-command and latency data to narrow a performance problem. This guide covers self-managed Redis; managed services may restrict configuration and diagnostic commands.

Configure the runtime log

A file-based deployment can use these settings in redis.conf:

# Runtime detail and destination
loglevel notice
logfile /var/log/redis/redis.log

# Optional additional output to the system logger
syslog-enabled yes
syslog-ident redis
syslog-facility local0

Create the log directory with permissions appropriate for the Redis service. Syslog availability depends on the operating environment. Keep explanatory comments on their own lines in Redis configuration files.

The familiar verbosity levels are debug, verbose, notice, and warning, from most detailed to least. notice is the normal default. Redis 8.2 also documents nothing, which suppresses ordinary logging; check your version before using additional values.

For a foreground container process, use:

daemonize no
logfile ""

An empty logfile directs output to stdout. Combining stdout logging with daemonize yes sends it to /dev/null, so the process model matters. The runtime or host still needs a retention policy for that output.

Runtime messages cover startup, persistence work, replication changes, and other server conditions according to the chosen level. A failed background save is a symptom, not a diagnosis of a full disk: inspect the surrounding error for permissions, storage failure, memory/fork problems, or another cause. Similarly, replication disconnects require checking both endpoints and the network.

Capture slow commands with SLOWLOG

# Threshold in microseconds: 10000 us = 10 ms
slowlog-log-slower-than 10000
# Maximum number of retained entries
slowlog-max-len 1024

Use these shell commands against the intended instance, adding your normal secure connection options as needed:

redis-cli SLOWLOG GET 10
redis-cli SLOWLOG LEN

Export evidence before clearing it. The following command removes the instance's current slow-log history:

redis-cli SLOWLOG RESET

A record includes an entry ID, Unix timestamp, execution duration in microseconds, command arguments, and, on relevant versions, client address and name. The record layout can evolve; for example, Redis 8.10 adds the original argument count. Long arguments and large argument lists can be truncated, so this is not a complete query archive.

The duration covers command execution, not client network transfer or the time waiting to be executed. A request can feel slow to the application without appearing in SLOWLOG. Conversely, one slow operation does not by itself prove that a key is frequently accessed.

SLOWLOG is a bounded in-memory history. Entries are evicted as it fills, and a server restart loses them. Setting the threshold to 0 records every command eligible for slow logging; a negative value disables it. Use a zero threshold only for a controlled diagnostic purpose and restore the intended value afterward. The command reference explains the fields and timing boundary.

Use MONITOR for a short, targeted investigation

redis-cli MONITOR

Stop the stream with Ctrl-C. It can reveal which commands and arguments an application sends, including an unexpected KEYS *, and usually includes the client endpoint. However, it is not a durable or complete audit log: administrative commands are excluded, command-specific redaction applies, and a disconnected observer loses its view. Data values can still be exposed.

Streaming activity adds work to the server and can reduce throughput substantially. Keep the session short, restrict access to its output, and measure its impact. Moving the investigation to a replica changes what traffic you observe and may miss the original client's identity or primary-only requests; a replica is not automatically an equivalent or risk-free observation point. See the MONITOR documentation for omissions and operational cost.

Separate latency events from slow-command records

The latency monitor records named internal events when they exceed a threshold in milliseconds:

redis-cli CONFIG SET latency-monitor-threshold 100
redis-cli LATENCY LATEST
redis-cli LATENCY HISTORY command
redis-cli LATENCY DOCTOR

command is an event category, not a placeholder for a command name such as GET. Other categories describe work such as persistence and fork-related activity. LATENCY LATEST shows which events have samples; an empty history can mean no event crossed the threshold after monitoring was enabled.

LATENCY DOCTOR summarizes the observed samples and offers diagnostic suggestions. Treat those suggestions as leads and compare them with workload and host data. The threshold defaults to disabled (0); a runtime CONFIG SET does not by itself persist across restart. Coordinate changes with the configuration owner and restore the prior threshold after a temporary investigation. Redis's latency-monitor guide documents the event model.

Understand keyspace notifications and persistence errors

notify-keyspace-events "KEA"

K enables keyspace channels, E enables key-event channels, and A is an alias for a documented set of event classes. It is not every possible event flag in every Redis version. For expiry notifications alone on key-event channels, Ex is narrower:

redis-cli SUBSCRIBE __keyevent@0__:expired

The subscription receives expiry events only if the configuration enables them. An expiry notification occurs when Redis removes an expired key, which can be later than the exact TTL deadline. Notifications use Pub/Sub rather than the runtime log, and disconnected subscribers miss events. They are useful for reactive behavior when that loss model is acceptable, not as durable audit history. Keyspace notification documentation lists the supported flags.

RDB and AOF persistence failures also deserve attention. MISCONF can be returned to clients when writes are stopped after an RDB background-save failure under stop-writes-on-bgsave-error; it does not always mean a full disk. Correlate the client error with runtime messages, persistence status, permissions, and storage capacity before changing the protection setting.

Collect runtime and slow-command data separately

Use DataKit file collection for the actual runtime log, or the supported container path for stdout. Validate event-time parsing and map Redis's severity markers to log severity. Use a known test message rather than assuming the parser matches the installed version.

Configure the DataKit Redis integration for metrics and slow-command data, with permissions required by the enabled collection features. File collection alone cannot read the in-memory SLOWLOG history. Check collection intervals against its bounded capacity, verify duration units, and avoid treating command arguments as harmless metadata.

Compare runtime errors, slow commands, and metrics over the same instance and time window. Alert on actionable conditions such as persistence failures or sustained latency with clear ownership; do not infer a hotspot solely from one slow-log record. Validate the error query and field mapping before enabling notifications.

Frequently asked questions

Why is there no ordinary full query log?

Redis separates runtime logging from command diagnostics to keep continuous work and storage bounded. SLOWLOG is performance-oriented, and MONITOR is a temporary observation stream. If durable auditing is required, design and validate an application, proxy, or supported service audit path with explicit coverage, redaction, and loss handling; neither diagnostic command automatically provides it.

Which production log level should I use?

Start with notice. Increase verbosity for a specific investigation and restore the previous setting afterward. redis-cli CONFIG SET loglevel verbose changes the runtime setting when permitted, but does not make that choice permanent in the configuration file.

Does Redis rotate its file automatically?

It does not provide a retention policy for the runtime file. Use your distribution's tested rotation setup or host logging service. Redis 8.2's normal file logger opens and closes the configured path for each write, so a blanket requirement for copytruncate is incorrect. Rename/create rotation requires appropriate ownership and permissions; copytruncate has a copy/truncate race that can lose records. Verify the installed version and collector behavior. Container stdout also needs driver or journal rotation.

How can I find and restrict KEYS * calls?

Use a brief MONITOR session when necessary, and correlate its client endpoint with application ownership. For long-term control, use Redis ACLs to restrict command access for the application user, then test legitimate workloads. rename-command is deprecated in favor of ACL rules. SLOWLOG can miss a fast KEYS call, and latency monitoring is not an authorization mechanism.

Further reading

• Redis configuration example, version 8.2
• Redis ACLs
• Redis 8.2 file logging implementation
• MongoDB logging
• MariaDB logging (Chinese)
• MySQL logging (Chinese)
• Log sampling (Chinese)

Technical references checked October 14, 2026.