How to Monitor a Redis Port for Uptime

Redis has a particular way of failing that doesn't look like failing at all. An instance running low on memory under its configured maxmemory policy will start silently evicting keys to stay within budget, and it'll keep responding to every command while it does, including the one asking whether it's healthy. Persistence can fail the same quiet way: if AOF writes or RDB snapshots have been failing for days, nothing about the running instance changes, it's still fast, still responsive, still answering PING with PONG. The problem only becomes visible the moment something restarts the process and there's nothing to reload from disk.

None of that shows up as a connection refused. A basic uptime check that just confirms the port is open will happily report Redis as healthy through all of it. That's not a reason to skip port monitoring, a Redis instance that's genuinely unreachable is still one of the more common and disruptive failures you'll hit, it's a reason to know exactly what a port check is telling you and what it isn't. Here's how to set one up with Downdar.

What You Will Need

A Downdar account and API key, and a Redis instance with its port (6379 by default) reachable from wherever Downdar's checkpoints connect from.

Creating a TCP Port Monitor

The /api/v1/monitors/create endpoint accepts a POST request specifying the monitor type, host, and port:

You can just as easily set this up from your Downdar dashboard instead, choose TCP as the check type and provide the host and port. Downdar will attempt a connection on the regular check interval and alert you the moment it can't reach the port at all.

What a TCP Check Actually Verifies (and Doesn't)

A successful connection to port 6379 means the process is running and something is listening there, that's it. It doesn't run a command against Redis, doesn't check memory usage, doesn't know whether keys are being evicted, and doesn't know whether persistence is writing successfully. All of that can be actively going wrong while the port check keeps passing every time.

That gap matters most for two things: eviction under memory pressure, where the instance is silently dropping data it was supposed to keep, and persistence failures, where a perfectly healthy-looking instance would lose everything on restart. If either of those is a real risk for how you're using Redis, cache-only workloads can usually tolerate eviction fine, but anything using Redis as a primary data store generally can't, it's worth adding an application-level check that actually issues a command and inspects the response, rather than relying on the port being open as a stand-in for "Redis is fine." A port monitor is still worth having regardless, an unreachable Redis instance is a real and common outage; it's just not the same signal as "Redis is behaving correctly."

Configuring Alerts

New monitors alert through your account's default channel unless you specify otherwise. To route this monitor somewhere specific, pass alert_channel_keys when creating it:

If Redis is sitting in front of your database as a cache layer, losing it usually means degraded performance rather than an outright outage, since most applications fall back to the database on a cache miss. If that's not true for your setup, if sessions, rate limiting, or queues depend on Redis directly, treat this alert with the same urgency as a database going down, and make sure it's routed accordingly.

Checking Monitor Status Programmatically

The /api/v1/monitors/status endpoint returns a monitor's current state if you want to surface it elsewhere.

A Note on Exposing Redis to Monitoring Traffic

This deserves more emphasis with Redis than with most services: unprotected, internet-facing Redis instances have a long, well-documented history of being found and wiped by automated scanners within hours, sometimes with a ransom note left behind in place of the data. Redis didn't require authentication by default for most of its history, and a lot of the damage traces back to instances that were opened to the internet, often temporarily, for exactly the kind of reason you're reading this article: to make monitoring or debugging easier.

Don't open port 6379 broadly to set up this monitor. Allowlist Downdar's checkpoint IP ranges specifically in your firewall or security group rules, check your account or support documentation for the current list. And regardless of monitoring, if Redis is reachable from anywhere outside a fully trusted network, requiring authentication (or ACLs, on newer Redis versions) isn't optional hardening, it's the baseline. If your Redis instance genuinely can't be reached without a VPN or private network path, an internal health-check endpoint monitored over HTTP from behind that same boundary is a better fit than exposing the port directly for external checks.

Get Started

Set up the port monitor first, it's the fastest way to catch a full outage. Decide separately, based on how critical Redis is to your application, whether you also need a command-level health check watching for eviction or persistence issues underneath it.