Is Redis Down? How to Diagnose & Fix Redis Outages in 2026

Redis is the world's most popular in-memory data store, used for caching, session storage, message queuing, and real-time leaderboards across millions of applications. When Redis goes down, the downstream effects are immediate: cache miss rates spike, API latency jumps, sessions get cleared, and queue-dependent features stall. Because Redis is often invisible until it fails, diagnosing outages quickly is a critical engineering skill.

Redis Down: Cloud vs. Self-Hosted Diagnosis

The first step is determining what kind of Redis deployment you're dealing with, because the diagnosis path is completely different.

How to Diagnose Self-Hosted Redis Down

Step 1: Test Connectivity with redis-cli

# Basic local ping
redis-cli ping

# Remote host with auth
redis-cli -h your-redis-host -p 6379 -a YOUR_PASSWORD ping

# With TLS (Redis 6+)
redis-cli -h your-redis-host -p 6380 --tls ping

Step 2: Check if Redis Process is Running

# Check process
ps aux | grep redis-server

# Check systemd service status
sudo systemctl status redis-server

# Check port is listening
ss -tlnp | grep 6379
# or
netstat -tlnp | grep 6379

Step 3: Read Redis Logs

# Default log location (Ubuntu/Debian)
sudo tail -100 /var/log/redis/redis-server.log

# Common error patterns:
# "Can't save in background: fork: Cannot allocate memory" → OOM
# "MISCONF Redis is configured to save RDB snapshots" → disk full
# "Warning: 32 bit instance detected" → memory limit issue

Step 4: Check Redis INFO for Health Metrics

# Get comprehensive stats
redis-cli info server | grep -E "redis_version|uptime_in_seconds|os"
redis-cli info memory | grep -E "used_memory_human|maxmemory_human"
redis-cli info stats | grep -E "rejected_connections|evicted_keys"
redis-cli info replication | grep -E "role|connected_slaves"

Common Redis Failure Modes & Fixes

1. Connection Refused (ECONNREFUSED)

The most common Redis error. Causes:

• Redis process is not running → sudo systemctl start redis-server
• Redis bound to localhost only → edit redis.conf: change bind 127.0.0.1 to bind 0.0.0.0 (with firewall protection)
• Firewall blocking port 6379 → open port in iptables/ufw/security group
• Wrong host/port in app config → double-check Redis URL environment variable

2. Out of Memory (OOM)

Redis consumed all available memory. Symptoms: writes fail with OOM command not allowed.

# Check current memory usage
redis-cli info memory | grep used_memory_human

# Set maxmemory limit (prevent OOM)
redis-cli config set maxmemory 2gb

# Set eviction policy for cache use case
redis-cli config set maxmemory-policy allkeys-lru

3. Redis Cluster Split-Brain

In Redis Cluster mode, network partition can cause a split-brain where multiple nodes think they're the primary. This manifests as inconsistent reads and writes across different application servers.

# Check cluster state
redis-cli cluster info | grep cluster_state
# Should return: cluster_state:ok

# Check node roles
redis-cli cluster nodes | awk '{print $1, $3, $8}'

4. Persistence Blocking Writes (BGSAVE / AOF)

Redis' background save (BGSAVE) or AOF rewrite can block writes if disk is full or slow:

# Check if background save is in progress
redis-cli info persistence | grep rdb_bgsave_in_progress

# Manually trigger save (use carefully in production)
redis-cli bgsave

# Disable persistence temporarily if disk is the issue
redis-cli config set save ""
redis-cli config set appendonly no

Restart Redis Safely

# Systemd (recommended)
sudo systemctl restart redis-server

# Graceful shutdown (saves RDB snapshot)
redis-cli shutdown save

# Docker
docker restart redis-container-name

# Force restart if unresponsive
sudo kill -9 $(pidof redis-server)
sudo systemctl start redis-server

Monitoring Redis in Production

Redis failures are often silent — your application just starts serving slower responses and higher error rates without a clear "Redis is down" error message. Production Redis monitoring should track:

• Connection availability — ping every 30 seconds from outside the app
• Memory usage — alert at 80% of maxmemory to prevent OOM
• Connected clients — spike in rejected connections = near-maxclients limit
• Eviction rate — sudden evictions indicate memory pressure
• Replication lag — replica lag > 5 seconds warrants investigation
• Command latency — p99 latency > 10ms for simple GET/SET indicates CPU or I/O contention