How to Monitor Your Redis Cache with Vigilmon

Redis is often the silent hero of your stack — until it isn't. Session stores, job queues, rate limiters, real-time leaderboards — they all fall apart when Redis goes down. And unlike your database, Redis failures can be subtle: memory limits hit, eviction starts silently, and your cache just quietly returns misses without anyone noticing.

This guide covers how to monitor Redis with Vigilmon — a free uptime monitoring platform for developers.

Why Redis Monitoring Is Different

Redis fails in ways that don't always surface immediately:

• Memory limit hit — Redis starts evicting keys, your hit rate crashes
• Persistence failure — RDB snapshots fail silently, you lose data on restart
• Replication lag — your Redis replica falls behind primary
• Connection pool exhaustion — your app queues Redis commands and hangs
• Keyspace explosion — a bug creates millions of keys, memory fills up

Some of these won't throw errors — they just degrade performance gradually.

Setting Up a Redis Health Endpoint

The best approach: expose an HTTP endpoint in your app that PINGs Redis and returns a health status.

Node.js / Express

const { createClient } = require('redis');

const redis = createClient({ url: process.env.REDIS_URL });
redis.connect();

app.get('/health/redis', async (req, res) => {
  try {
    const result = await redis.ping();
    if (result === 'PONG') {
      return res.json({ status: 'ok', redis: 'connected' });
    }
    throw new Error('Unexpected PING response');
  } catch (err) {
    res.status(503).json({ status: 'error', redis: err.message });
  }
});

Python / FastAPI

import redis
import os
from fastapi import FastAPI
from fastapi.responses import JSONResponse

app = FastAPI()
r = redis.from_url(os.environ['REDIS_URL'], socket_timeout=2)

@app.get('/health/redis')
def health_redis():
    try:
        r.ping()
        return {'status': 'ok', 'redis': 'connected'}
    except redis.ConnectionError as e:
        return JSONResponse(status_code=503, content={'status': 'error', 'redis': str(e)})

PHP / Laravel

Route::get('/health/redis', function () {
    try {
        Redis::ping();
        return response()->json(['status' => 'ok', 'redis' => 'connected']);
    } catch (\Exception $e) {
        return response()->json(['status' => 'error', 'redis' => $e->getMessage()], 503);
    }
});

Configuring Vigilmon

1. Sign up at vigilmon.online
2. Add HTTP Monitor → your /health/redis endpoint
3. Check interval: 1 minute
4. Alert threshold: 1 failure (Redis should never be down)
5. Add Slack/email/PagerDuty notifications

TCP Port Monitor (Secondary)

Redis listens on port 6379 by default. Add a TCP monitor:

• Host: your Redis server
• Port: 6379
• This catches Redis process crashes even if your app is down

Advanced Redis Health Metrics

Once basic connectivity is covered, check these critical Redis metrics:

Memory Usage

INFO memory
# Key fields:
# used_memory_human: 2.50G   (current usage)
# maxmemory_human: 4.00G     (configured max)
# mem_fragmentation_ratio: 1.2  (>1.5 is bad)

Alert when used_memory exceeds 80% of maxmemory.

Eviction Rate

INFO stats
# evicted_keys: 0   (should be 0 unless using LRU eviction intentionally)

Any non-zero evicted_keys means Redis is dropping your data.

Connection Count

INFO clients
# connected_clients: 42
# blocked_clients: 0  (should be 0)

Replication Health

INFO replication
# role: master
# connected_slaves: 1
# master_repl_offset: 12345
# slave0:ip=10.0.0.2,port=6379,state=online,offset=12345,lag=0

Expose these as additional health endpoints:

app.get('/health/redis/memory', async (req, res) => {
  const info = await redis.info('memory');
  const usedBytes = parseInt(info.match(/used_memory:(\d+)/)[1]);
  const maxBytes = parseInt(info.match(/maxmemory:(\d+)/)[1]);
  const pct = maxBytes > 0 ? (usedBytes / maxBytes * 100).toFixed(1) : 0;

  if (maxBytes > 0 && usedBytes / maxBytes > 0.9) {
    return res.status(503).json({ status: 'warning', usage_pct: pct });
  }
  res.json({ status: 'ok', usage_pct: pct });
});

Response Time Thresholds

A Redis PING should be near-instant:

• <5ms: Healthy
• 5-50ms: Slightly loaded (network latency or CPU pressure)
• >50ms: Investigate — possible memory pressure or slow commands

In Vigilmon, set a response time alert at 100ms for your /health/redis endpoint.

Alerting Matrix

Scenario	Severity	Response
TCP 6379 not responding	P0 Critical	Redis process down, restart immediately
HTTP health returns 503	P1 Critical	Connection error, check logs
Memory >85% of max	P1 Warning	Expand instance or audit keys
Eviction rate >0	P2 Warning	Review TTLs or increase memory
Response time >100ms	P2 Warning	Check for slow commands

Common Redis Monitoring Mistakes

Only checking TCP port — Redis can accept connections but be in a bad state (blocked by a slow LRANGE, near OOM). Always add an application-level health check.

Not monitoring evictions — Silent key eviction can break session stores, rate limiters, and caches in ways that look like application bugs.

Ignoring replica lag — If you're reading from Redis replicas, replication lag can cause stale reads that are hard to debug.

No maintenance windows — Redis restarts during RDB saves can briefly block. Mark these in Vigilmon as scheduled maintenance to avoid false alert fatigue.

Quick Setup Checklist

• [ ] /health/redis endpoint with PING check
• [ ] TCP monitor on port 6379
• [ ] Memory usage endpoint with 80% alert threshold
• [ ] Replication health endpoint (if using replica)
• [ ] Response time alert at 100ms
• [ ] On-call alert for P0/P1, Slack for P2

Start monitoring Redis for free with Vigilmon →

---

Vigilmon is an uptime monitoring platform for developers. Free tier includes 10 monitors with 1-minute checks from multiple global regions.