Is Redis Down? How to Check Redis Cloud and Redis Status Right Now

Statusfield Team
7 min read

Redis connections timing out, commands hanging, or Redis Cloud unreachable? Learn how to check if Redis is down right now, what causes outages, and how to protect your application when Redis fails.

Check current Redis status: statusfield.com/services/redis

Redis is the backbone of application caching, session storage, rate limiting, and real-time queues. When Redis goes down, the impact cascades fast — API responses slow to a crawl, session authentication fails, queues back up, and rate limiters stop working. Here's how to confirm whether Redis is down and what to do about it.

Is Redis Down Right Now?

Check these in order:

  1. Statusfield — Redis status — real-time monitoring of Redis's managed service health.
  2. Redis's official status pagestatus.redis.io covers Redis Cloud (the managed offering) across all regions.
  3. Twitter/X — search redis down or redis cloud down sorted by Latest. Backend engineers report connection issues quickly during incidents.
  4. Your application error logsECONNREFUSED, ETIMEDOUT, or Connection refused errors pointing to your Redis endpoint are the clearest signal.

Redis Deployment Types That Can Fail Differently

Deployment TypeFailure Mode
Redis Cloud (redis.io)Managed service outage — connection to cloud-hosted instance fails; check status.redis.io
Self-hosted Redis (Linux)Process crash, OOM kill, or disk full — check redis-cli ping locally
AWS ElastiCache (Redis)AWS infrastructure incident in your region — check status.aws.amazon.com
Azure Cache for RedisAzure infrastructure incident — check status.azure.com
GCP MemorystoreGCP infrastructure incident — check status.cloud.google.com
Upstash (serverless Redis)Upstash platform incident — check status.upstash.com

If you're on a managed Redis service, always check the provider's status page first — the issue is rarely in Redis itself, and usually in the platform hosting it.

Common Errors During a Redis Outage

ErrorLikely cause
ECONNREFUSED 127.0.0.1:6379Redis process not running locally (check redis-cli ping)
ETIMEDOUT or Connection timed outRedis unreachable over network — firewall, VPC, or provider outage
NOAUTH Authentication requiredRedis is running but requires a password (config change, not an outage)
OOM command not allowed when used memory > maxmemoryRedis hit memory limit — not an outage, but commands are being rejected
READONLY You can't write against a read-only replicaFailover occurred; your client is connected to a replica, not the primary
ERR max number of clients reachedRedis hit maxclients — connection pool exhaustion, not necessarily an outage
LOADING Redis is loading the dataset in memoryRedis restarted and is loading an RDB/AOF snapshot — temporary (seconds to minutes)
Could not connect to Redis at redis.cloud.example.com:6379: Connection refusedManaged Redis instance unreachable — check provider status page

Why Redis Goes Down

Memory exhaustion (OOM). Redis is an in-memory data store. When used memory exceeds maxmemory, Redis either starts evicting keys (if an eviction policy is configured) or rejects write commands entirely. Unbounded key growth, large values, or missing TTLs cause this. If the host OS OOM-killer kicks in, the Redis process is killed.

Network partitions. Redis Sentinel and Redis Cluster both have quorum requirements. A network partition that isolates a majority of nodes can leave replicas unable to elect a new primary, causing the cluster to go read-only or go down entirely.

Slow commands blocking the event loop. Redis is single-threaded (for command processing). A single KEYS * on a large dataset, or an expensive SORT, LRANGE, or Lua script blocks all other commands for its entire duration. This isn't an outage — but it looks like one.

Replication lag becoming failover. Under high write load, replicas can fall behind the primary significantly. If the primary fails during high replication lag, the replica that takes over may be seconds behind, causing apparent data loss and application errors.

Persistence (RDB/AOF) I/O. BGSAVE (RDB snapshot) forks the process and can cause significant memory pressure on writes (copy-on-write). AOF rewrite is similarly disruptive. On disk-constrained hosts, these operations can fail or cause the Redis process to exit.

What To Do During a Redis Outage

Immediate actions

  1. Run redis-cli -h <host> -p <port> ping — if it returns PONG, Redis is reachable. If it hangs or errors, it's unreachable.
  2. Check your managed Redis provider's status page (Redis Cloud, ElastiCache, Upstash, etc.)
  3. Check whether the issue is write-specific: run redis-cli info replication — if role:slave, your client is hitting a replica after a failover

Application-level mitigations

Add a circuit breaker around Redis calls:

import redis
from functools import wraps
 
r = redis.Redis(host='localhost', socket_connect_timeout=1, socket_timeout=0.5)
 
def with_redis_fallback(default=None):
    def decorator(func):
        @wraps(func)
        def wrapper(*args, **kwargs):
            try:
                return func(*args, **kwargs)
            except (redis.RedisError, ConnectionError):
                return default
        return wrapper
    return decorator
 
@with_redis_fallback(default=None)
def get_cached_user(user_id):
    return r.get(f"user:{user_id}")

Use connection pooling with timeouts:

pool = redis.ConnectionPool(
    host='redis.example.com',
    port=6379,
    max_connections=20,
    socket_connect_timeout=2,
    socket_timeout=1,
)
r = redis.Redis(connection_pool=pool)

Degrade gracefully when Redis is unavailable:

  • Cache miss fallback: If Redis is down, fall through to the database. Slower, but functional.
  • Session storage fallback: If sessions are in Redis, add a cookie-based fallback or serve from a secondary store.
  • Rate limiting: If your rate limiter depends on Redis, either fail-open (allow requests through) or fail-closed (return 429) based on your threat model.
  • Queue fallback: If Redis-backed queues are unavailable, buffer jobs in a database table or drop non-critical ones.

If Redis OOM-killed your process

# Check if Redis is running:
systemctl status redis
 
# Restart Redis:
systemctl restart redis
 
# Check memory usage after restart:
redis-cli info memory | grep used_memory_human
 
# Set a maxmemory policy to prevent future OOM kills:
redis-cli config set maxmemory-policy allkeys-lru

Monitor Redis Automatically

When Redis is in your application's critical path — caching, sessions, queues — you need to know about incidents the moment they happen, not after users start reporting errors.

Statusfield continuously monitors Redis's managed service health, sending instant alerts when incidents are detected — before your application's error rate spikes.

Start monitoring Redis →


Frequently Asked Questions

Is Redis Cloud down right now?

Check statusfield.com/services/redis for real-time Redis Cloud status, or status.redis.io for Redis's official status page.

Why is my Redis connection timing out?

The most common causes: Redis process not running, network firewall blocking port 6379, Redis hit maxclients limit, or a managed Redis provider outage. Run redis-cli -h <host> ping to confirm reachability. If it returns PONG, your application's connection pool may be exhausted.

What does READONLY You can't write against a read-only replica mean?

After a Redis failover, your client may be connected to a replica instead of the new primary. Update your connection string to point to the new primary, or use Redis Sentinel/Cluster which handles failover routing automatically.

Is it Redis or my application that's causing the slowdown?

Run redis-cli slowlog get 10 to see the 10 slowest recent commands. If you see KEYS *, expensive SORT/LRANGE operations, or large Lua scripts, those are blocking your event loop — not an outage, but an application issue. Fix the slow commands.

How do I prevent Redis outages from taking down my application?

Implement a circuit breaker around all Redis calls, set connect and command timeouts (1–2 seconds), use connection pooling, and design fallback paths for each Redis use case (cache miss → DB, sessions → cookie, queues → buffer). These patterns let your application degrade gracefully instead of failing completely.