How to monitor

How to monitor Redis

Redis backs your cache, sessions and queues — when it stalls, everything above it slows or breaks. Here's how to monitor Redis reachability and health without exposing it.

StatusCat2 min read

Redis usually sits quietly behind your app, powering the cache, sessions, rate limiting and job queues. When it stalls or goes down, the symptoms show up everywhere else — slow pages, failed logins, stuck queues — and it's not always obvious Redis is the cause. Monitoring it directly gives you a clear signal.

Here's how to monitor Redis reliably, without exposing it to the internet.

Two solid approaches

1. TCP reachability check (quick baseline)

A TCP check on Redis's port (default 6379) confirms it's reachable and accepting connections. This is useful when Redis is on a publicly-reachable host. If Redis is private (as it usually should be), an external check can't reach it — use the command heartbeat below instead.

2. Command heartbeat (stronger)

The best signal is a job that actually issues a Redis command and reports health:

# Runs on a schedule inside your network
redis-cli -u "$REDIS_URL" ping | grep -q PONG \
  && curl -fsS -m 10 https://statuscat.co/ping/your-redis-heartbeat-id > /dev/null
  • PING returning PONG proves Redis can serve commands.
  • The && means the ping only fires on success — so a failure becomes a missing heartbeat, and StatusCat alerts you.
  • Nothing is exposed publicly; the job reaches out.

For an even stronger check, do a SET/GET/DEL round-trip on a throwaway key to confirm reads and writes both work.

What else to watch

  • The app's use of Redis — a /health endpoint that touches Redis will fail if Redis is unhealthy (how to monitor an API).
  • Queue workers — a heartbeat from your queue processor catches a stuck consumer even if Redis itself is up (how to monitor a cron job).
  • Memory & evictions — emit these from inside and let a failing heartbeat page you when a threshold is crossed.

Put it together

A solid Redis setup is usually a command heartbeat ("can it serve commands?"), a TCP/host check ("is it reachable?"), and a worker heartbeat ("is the queue draining?"). Wire alerts and escalation so the right person hears about it fast.

StatusCat supports TCP, ICMP and heartbeat monitors alongside HTTP/DNS/SSL checks, free for 50 monitors. New to monitoring? Start with what uptime monitoring is.

Frequently asked questions

How do I monitor Redis without exposing it publicly?
Keep it private and use a heartbeat: a small scheduled job inside your network runs a PING (or SET/GET round-trip) and pings StatusCat on success. If the check fails, the heartbeat stops and you're alerted.
Is a TCP check on port 6379 enough?
It's a good baseline — it confirms Redis is reachable — but a PING or SET/GET round-trip is stronger because it proves Redis can actually serve commands, not just accept a connection.
What Redis problems should I watch for?
Reachability (is it up?), responsiveness (can it serve commands?), and memory pressure or evictions. Reachability and responsiveness are easy to check externally; memory metrics are best emitted from inside and turned into a failing heartbeat when a threshold is crossed.

Keep reading

GuidesHow to monitor SSL certificate expiry (and never get caught out)Expired TLS certificates cause instant, total outages — and they're completely preventable. Here's how certificate expiry monitoring works and how to set it up in minutes.GuidesHow to monitor an API (the right way)A 200 response doesn't mean your API works. Here's how to monitor an API properly — status, latency, payload correctness, auth and SSL — so you catch real failures before your customers do.GuidesHow to monitor a cron job (with heartbeats)Cron jobs fail silently — the job stops, the server reboots, a deploy breaks the schedule, and nobody notices until data is missing. Here's how heartbeat monitoring catches it.