Valkey slowlog monitoring
The slowlog is the best built-in tool for finding expensive commands - and it's a 128-entry in-memory ring buffer that rotates fastest exactly when things go wrong. Slowlog monitoring means getting that data out and keeping it.
The questions a raw slowlog can't answer
SLOWLOG GET shows you recent entries. During an incident post-mortem, operators need context:
- Which commands were slow - and were they slow before today?
- Which command patterns are responsible for most of the slow time?
- Which clients or services generated them?
- When did the behavior begin, and did a deploy correlate?
- Did the slow commands coincide with memory pressure, evictions, or a traffic burst?
How BetterDB turns the slowlog into an investigation tool
Persistence beyond the ring buffer
Every slowlog entry is captured continuously and stored (PostgreSQL or SQLite), so a 128-entry buffer overwritten during an incident is no longer a dead end. Query any time range, hours or weeks later.
Pattern aggregation
Entries are normalized into patterns (GET user:*, FCALL session_cleanup) with frequency and average duration - so you see that one pattern accounts for 57% of slow time instead of scrolling raw entries.
Client attribution
Slow entries carry client information, cross-referenced with connection history, so "which service did this" has an answer.
Unified timeline
Slowlog markers, ops bursts, and anomaly flags render on one time axis - the write flood, CPU saturation, and slow queries line up visually.
Cluster-wide aggregation
In cluster mode, slowlogs from all nodes are aggregated into one view (also exposed as an MCP tool), instead of node-by-node SLOWLOG GET.
Deeper capture when you need it
MONITOR capture sessions record real traffic on demand - live tail, filter, replay, export - for the cases where the slowlog alone is not enough.
Real-world walkthrough: the same incident debugged with and without persisted slowlog →
FAQ
What is the Valkey slowlog?
The slowlog is an in-memory log of commands that exceeded a configurable execution-time threshold (slowlog-log-slower-than, in microseconds). It records the command, its arguments, execution time, timestamp, and client. It exists in both Valkey and Redis and is the primary built-in tool for finding expensive commands.
Why do slowlog entries disappear?
The slowlog is a fixed-size ring buffer (slowlog-max-len, commonly 128 entries) held in memory. New entries overwrite the oldest, and the log is emptied on restart. During an incident - exactly when slow commands are most frequent - the buffer rotates fastest, so by the time you investigate, the evidence is often gone. Persisting entries externally is the standard fix.
How should I configure the slowlog?
Two parameters: slowlog-log-slower-than sets the threshold in microseconds (10000 = 10ms is a common starting point; 0 logs everything, -1 disables), and slowlog-max-len sets the buffer size. With an external collector like BetterDB polling continuously, a larger buffer mainly protects against entries rotating away between polls.
What is the difference between SLOWLOG and COMMANDLOG?
SLOWLOG only records commands that were slow to execute. Valkey 8.1+ adds COMMANDLOG, which also records commands with large request or reply payloads - problems that are invisible to the slowlog because execution time was fine. BetterDB persists and pattern-analyzes both.
Does slowlog monitoring add overhead?
The slowlog itself is maintained by Valkey with negligible cost. BetterDB polls it and persists new entries; measured total monitoring overhead is sub-1%, with the benchmark methodology published on the blog.
On Valkey 8.1+? The slowlog's successor catches more: COMMANDLOG monitoring →
Start persisting your slowlog before the next incident
Ready to get started?
Start monitoring in minutes - no infrastructure to maintain. Team collaboration, agent-based monitoring for private databases, and more. Or self-host - open source core, zero lock-in.