Valkey COMMANDLOG monitoring
The slowlog only catches commands that were slow to execute. Valkey 8.1's COMMANDLOG also catches commands that were large - oversized requests and replies that hurt latency through bandwidth and buffering, while looking fast on paper.
One command, three ways to be a problem
| Log type | Records | What it catches |
|---|---|---|
| slow | Commands that exceeded the execution-time threshold | The traditional slowlog: expensive commands, O(N) scans, blocking operations. |
| large-request | Commands with large request payloads | Bulk writes (MSET, big HSET batches) that consume input bandwidth and buffer memory - even when they execute fast. |
| large-reply | Commands returning large reply payloads | Oversized reads (HGETALL, LRANGE on huge structures) that saturate output bandwidth and risk client timeouts. |
Why large payloads matter even when execution is fast
- • Network bandwidth consumed by large transfers
- • Memory pressure from buffering large payloads
- • Client timeout risk from slow network transfers
- • Bottlenecks invisible to the traditional slowlog, because execution time was fine
What BetterDB adds on top
Persistence beyond rotation
Valkey's COMMANDLOG, like SLOWLOG, is a bounded in-memory buffer - it rotates away. BetterDB persists entries with time-range filtering, so the evidence still exists when you investigate hours later.
Pattern aggregation
Entries are grouped into command patterns (e.g. HGETALL user:*) with frequency and average size, so you see which access pattern is responsible rather than scrolling raw entries.
Prometheus metrics
Totals and per-pattern series (betterdb_commandlog_large_request_by_pattern, betterdb_commandlog_large_reply_by_pattern) let you correlate large replies with output bandwidth and alert on regressions.
Graceful fallback
On Redis or Valkey below 8.1, capability detection disables the COMMANDLOG views cleanly and the classic persistent slowlog continues to work.
Typical wins: spotting an HGETALL pattern that should be HMGET, rate-limiting a bulk MSET job, and correlating large replies with output bandwidth spikes.
FAQ
What is Valkey COMMANDLOG?
COMMANDLOG is Valkey's evolution of SLOWLOG, introduced in Valkey 8.1. Instead of only recording commands that were slow to execute, it maintains three logs: slow (the traditional slowlog), large-request (commands with large request payloads), and large-reply (commands returning large replies).
How is COMMANDLOG different from SLOWLOG?
SLOWLOG records only commands that exceed an execution-time threshold. COMMANDLOG additionally records commands with large request or reply payloads - which can degrade performance through network bandwidth and buffer memory even when execution time is fast. SLOWLOG still exists in Valkey; COMMANDLOG supersedes and extends it.
Which versions support COMMANDLOG?
COMMANDLOG requires Valkey 8.1 or newer. Redis does not have COMMANDLOG in any version. BetterDB detects the capability per connection: on Valkey 8.1+ all three log types are collected; on Redis 6+ or older Valkey the COMMANDLOG views are disabled gracefully and persistent SLOWLOG analysis continues to work.
Why do large replies matter if the command is fast?
A fast HGETALL that returns 5 MB still has to serialize the payload, buffer it, and push it through the network. At volume this saturates output bandwidth, inflates client-side latency, and can trigger client timeouts - none of which shows up in the slowlog, because execution time was fine. The standard fix is retrieving specific fields (HMGET) or paginating reads.
Does monitoring COMMANDLOG add overhead?
The log itself is maintained by Valkey; BetterDB polls and persists it like the slowlog. BetterDB's measured monitoring overhead is sub-1% - benchmarked methodology is published on the blog.
Running Valkey 8.1? See your large replies now
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.