Redis Debugging Checklist

redis-cli, INFO, memory, clients, slowlog and cache incident evidence. Last updated August 31, 2026.

Redis issues usually appear as slow APIs, login failures, queue delays, missing sessions or sudden memory pressure. Redis documents redis-cli as the command-line tool for interactive and scripted work. Use this checklist to gather safe evidence before flushing keys, restarting services or changing application code.

Connectivity and identity

redis-cli ping
redis-cli info server
redis-cli info clients
redis-cli info memory
redis-cli config get bind
redis-cli config get port

Service and logs

systemctl status redis --no-pager
systemctl status redis-server --no-pager
journalctl -u redis -n 120 --no-pager
journalctl -u redis-server -n 120 --no-pager
ss -tulpn | grep redis 2>/dev/null

Memory and keyspace

Memory checks should come before cache-clearing decisions. A cache flush can hide the symptom and create a traffic spike against the database.

redis-cli info memory
redis-cli info stats
redis-cli info keyspace
redis-cli dbsize
redis-cli --bigkeys
redis-cli --memkeys

Clients, slowlog and latency

redis-cli client list
redis-cli client list | wc -l
redis-cli slowlog len
redis-cli slowlog get 10
redis-cli latency latest
redis-cli latency doctor

Common Redis failure patterns

Symptom	Check first	Likely direction
API suddenly slow	`slowlog get`, latency, connected clients	Slow commands, connection storms or network pressure.
Sessions disappear	keyspace, TTL policy, memory, eviction settings	Keys expire or memory policy evicts them.
Queue backlog grows	clients, blocked workers, list/stream size	Consumers are down or slower than producers.
Memory keeps rising	`info memory`, `--bigkeys`, key prefixes	Unbounded keys, missing TTL or large payloads.
App cannot connect	bind, port, auth, firewall, DNS, container network	The application runtime points at the wrong Redis endpoint.

Safe key inspection

Avoid KEYS * on busy production systems. Use cursor-based scanning and inspect a narrow prefix when possible.

redis-cli --scan --pattern 'session:*' | head -50
redis-cli ttl session:example
redis-cli type session:example
redis-cli memory usage session:example

Incident evidence bundle

date -Is
hostname
redis-cli ping
redis-cli info server
redis-cli info clients
redis-cli info memory
redis-cli info keyspace
redis-cli slowlog get 10

The safest Redis debugging order is connectivity, identity, memory, keyspace, clients, slowlog and latency. Restart or flush only after the evidence explains the failure.