Docs
How the scan works, what it finds, and how to act on it.
1. Run a scan
The scanner is a single read-only binary. Point it at any reachable Redis (OSS, ElastiCache, Memorystore, self-hosted). It samples the keyspace, parses SLOWLOG/LATENCY/INFO, and optionally greps your repo for command anti-patterns.
2. Read the findings
Each finding has a severity, category (keyspace / bigkey / hotkey / slowlog), the evidence, an estimated cost (CPU / latency / memory), and a concrete fix. Findings are sorted by impact.
3. Apply the fix
Fixes are specific: replace KEYS pat:* with SCAN + a sorted-set index; shard a 600MB hash; add a client TTL cache on a hot key. The index advisor emits the migration snippet.
4. Gate it in CI
Add the linter to CI so a new KEYS/blocking-range command fails the build before it ships. Schedule weekly scans (Team) to catch live regressions and diff against last week.
What it detects
| Category | Examples | Why it hurts |
|---|---|---|
| Keyspace O(N) | KEYS, blocking SMEMBERS/HGETALL/LRANGE 0 -1, unbounded SCAN loops | Single-threaded Redis stalls all clients during an O(N) sweep — the #1 latency-cliff cause. |
| Big keys | Multi-MB strings/hashes/lists, ever-growing collections | Slow serialization, memory pressure, blocking deletes, replication lag. |
| Hot keys | One key receiving a large share of ops | Shard imbalance, CPU hotspot, no horizontal relief without a client cache. |
| Slowlog / latency | Recurring slow commands, fork/AOF/RDB latency spikes | Tail-latency that violates SLOs and is invisible on averages. |
| Config smells | No maxmemory-policy, dangerous save cadence, missing eviction | OOM kills, surprise data loss, or unbounded growth. |
Privacy: the scanner is read-only and runs inside your network. It reads command metadata, key names/sizes (sampled), and stats — not your values. On the self-hosted plans, only the generated findings report leaves the box, and only if you choose to export it.