How to monitor Redis

Q: Which maxmemory-policy should I use?

For a pure cache, allkeys-lru or allkeys-lfu. For anything that must not lose data (sessions, Sidekiq or Celery queues), noeviction, plus a memory alert well before the limit, because writes will fail when it is reached.

Monitor Redis by checking that it answers PING, then watching used memory against maxmemory, evicted keys, the last RDB or AOF write status, the replica link and the cache hit rate. Run redis-cli INFO by hand to see each one; Vigil's agent collects the same INFO fields every interval and alerts on limits you set.

Updated 3 October 2026 · by PuzariCloud · commands checked against current releases

What can go wrong with Redis

maxmemory reached. With the noeviction policy writes fail with OOM command not allowed when used memory > 'maxmemory'. With an eviction policy Redis silently drops keys instead, which is fine for a cache and a disaster for sessions or queues. With no maxmemory at all, the kernel's OOM killer decides.
Persistence fails and writes stop. If a background save fails (fork fails, disk full) and stop-writes-on-bgsave-error is on (the default), Redis refuses writes with MISCONF Redis is configured to save RDB snapshots, but it's currently unable to persist to disk.
Replica link down. master_link_status:down on a replica means it is serving stale data, and Sentinel or your failover has nothing current to promote.
Slow commands block everyone. Redis runs commands on one thread. A KEYS *, a huge SMEMBERS or a big Lua script stalls every other client for its whole duration.
Client limit. maxclients defaults to 10,000; a leaking client pool hits it and new connections are refused.

The signals that matter, with alert thresholds

Signal	Alert when	Why it matters
PING	no PONG twice in a row	Down or unreachable.
used_memory / maxmemory	≥ 80% warn, ≥ 90% page	Before writes fail or evictions start.
evicted_keys	any increase on a session or queue store	Data is being dropped.
rdb_last_bgsave_status / aof_last_write_status	anything other than ok	Writes may be refused next.
master_link_status, master_last_io_seconds_ago	down, or > 30 s	Replica is stale.
Hit rate (keyspace_hits / hits+misses)	< 80% for a cache	The cache is not doing its job; for a queue, ignore.
connected_clients / maxclients	≥ 80%	Connection leak.
mem_fragmentation_ratio	> 1.5 sustained	RSS far above data size; consider activedefrag or a restart.

Thresholds are starting points. Tune them after a week of data: an alert nobody acts on should be raised or removed.

How to check Redis by hand

Alive?

redis-cli ping

Memory and policy

redis-cli INFO memory | grep -E 'used_memory_human|maxmemory_human|maxmemory_policy|mem_fragmentation_ratio'

Evictions and hit rate

redis-cli INFO stats | grep -E 'evicted_keys|keyspace_hits|keyspace_misses'

Persistence status

redis-cli INFO persistence | grep -E 'rdb_last_bgsave_status|aof_last_write_status|rdb_last_save_time'

Replication

redis-cli INFO replication

Slowest recent commands and live latency

redis-cli SLOWLOG GET 10
redis-cli --latency

If Redis has a password, export REDISCLI_AUTH instead of passing -a, so the password does not land in your shell history or the process list.

How to watch Redis with Vigil

Add the host under Servers and run the one-line installer it shows (curl -fsSL https://puzaricloud.in/install-server-agent.sh | sh -s -- --token <token>). The agent is one Python file with no dependencies; CPU, memory, disk, inode and load rules start working with the first report.
Add Redis under databases in /etc/vigil-agent.json (example below, rediss:// for TLS). The agent runs redis-cli INFO, CONFIG GET maxclients and SLOWLOG LEN, passing the password through REDISCLI_AUTH. Check it with sudo vigil-server-agent --db-test.
You get memory, evicted keys, clients, ops/s, hit rate, blocked clients and, on replicas, seconds since the last contact with the primary. An automatic "Redis (auto)" dashboard appears once data arrives.
Tune the rules: the default 90% hit-rate minimum suits a cache; set it to 0 if this Redis is a queue or a session store. Add the persistence command below with the limit redis_save_failed = 1.
Add redis-server (or redis, depending on the distribution) to the systemd services to watch.

/etc/vigil-agent.json (add to the existing keys)

{
  "databases": [
    {"name": "cache", "dsn": "redis://:secret@127.0.0.1:6379/0"}
  ],
  "commands": {
    "redis_save_failed": "redis-cli INFO persistence | grep -c -E 'rdb_last_bgsave_status:err|aof_last_write_status:err' || true"
  }
}

Every alert goes to the channels you pick: email, Slack, Telegram, Discord, Microsoft Teams, Pushover, webhooks or on-call paging. Failures are confirmed by a second check before anyone is woken up.

Redis monitoring FAQ

Which maxmemory-policy should I use?

For a pure cache, allkeys-lru or allkeys-lfu. For anything that must not lose data (sessions, Sidekiq or Celery queues), noeviction, plus a memory alert well before the limit, because writes will fail when it is reached.

Is a low hit rate always bad?

Only for a cache. A Redis used as a queue or a lock store has misses by design. The rule only evaluates while the instance is serving traffic, and setting the minimum to 0 turns it off.

Can I monitor a managed Redis (ElastiCache, Upstash)?

If the agent's host can reach it with redis-cli, yes: point the DSN at it. Some managed services disable CONFIG; the agent then reports the rest without the client limit.