Redis max number of clients reached: maxclients and rejected_connections

Redis is rejecting new client connections. Applications see connection errors or timeouts. The rejected_connections counter in INFO stats is climbing. These are the hallmarks of hitting the maxclients limit, and the situation can worsen rapidly if client retry logic amplifies the problem.

The maxclients directive (default 10,000) sets a hard ceiling on simultaneous connections. When the limit is reached, Redis sends an error to the new client and closes the connection immediately. The rejected_connections counter increments for every refused connection. Because this counter is cumulative, any increase during your monitoring window is an active incident.

What makes this failure insidious is the retry cascade. Applications that cannot connect typically retry. If the retry interval is short, the burst of new connection attempts can exceed the rate at which existing connections are freed, creating a feedback loop that extends the outage far beyond the original trigger.

What this means

Redis limits concurrent connections via maxclients. The default is 10,000, but the effective ceiling can be lower than what you configured if the OS file descriptor limit is too low.

Internal file descriptor overhead. Redis needs 32 file descriptors for internal use (persistence files, logging, replication sockets) in addition to the client connection count. Setting maxclients 10000 means Redis requires at least 10,032 file descriptors from the OS.

OS file descriptor limit (ulimit -n). The kernel imposes its own cap on open file descriptors per process. If ulimit -n is lower than maxclients + 32, Redis silently reduces maxclients to ulimit_value - 32 at startup and logs a warning. On a system with the default ulimit -n of 1024, an instance configured with maxclients 10000 will actually accept only roughly 992 connections.

The connection count that counts toward maxclients is not just connected_clients. On a primary with replicas or a cluster node, the total includes connected_clients, connected_slaves (replica connections), and cluster_connections (cluster bus connections, Redis 6.2+). Monitoring only connected_clients understates actual capacity usage on primaries or cluster nodes.

When the total reaches the effective maxclients, Redis rejects new connections and rejected_connections increments. The rejection is immediate: Redis sends an error response and closes the socket.

flowchart TD
    A["connected_clients reaches effective maxclients"] --> B["Redis rejects new connections"]
    B --> C["rejected_connections increments"]
    C --> D["Apps see connection errors"]
    D --> E{"Application retry behavior"}
    E -->|"Retry immediately"| F["Burst of new attempts"]
    F --> B
    E -->|"Exponential backoff"| G["Pressure decreases gradually"]
    B --> H["Existing idle connections freed by timeout"]
    H --> A

Common causes

Quick checks

# Check if rejected_connections is actively increasing (run twice, seconds apart)
redis-cli INFO stats | grep rejected_connections

# Check current client connections and configured limit
redis-cli INFO clients | grep connected_clients
redis-cli CONFIG GET maxclients

# Check the effective file descriptor limit for the Redis process
cat /proc/$(pidof redis-server)/limits | grep "Max open files"

# Check connection churn rate
redis-cli INFO stats | grep total_connections_received

# List all clients: look for high idle (leaks), age=0 (churn), high omem (slow consumers)
redis-cli CLIENT LIST

# Check if idle timeout is configured (0 = disabled, connections persist indefinitely)
redis-cli CONFIG GET timeout

# On cluster nodes, check cluster bus connections consuming slots
redis-cli INFO clients | grep cluster_connections

# On primaries, check replica connections consuming slots
redis-cli INFO replication | grep connected_slaves

How to diagnose it

1. Confirm the rejection is active. Run redis-cli INFO stats | grep rejected_connections twice, 5 seconds apart. If the value increased, rejections are ongoing.

2. Verify the effective maxclients. Compare CONFIG GET maxclients with the OS limit. If the OS limit is below maxclients + 32, Redis reduced the effective limit at startup. Check the Redis startup log for the warning message.

3. Count all connection types. Compute the true capacity usage: connected_clients + connected_slaves + cluster_connections. Compare this total to the effective maxclients. If they are equal, the ceiling is hit.

4. Identify the connection pattern from CLIENT LIST. Examine the output for:

   • High idle values across many connections: connection leak. The application opened connections but is not closing them.
   • age=0 or age=1 on many connections: connection churn. The application pool is misconfigured, rapidly creating and destroying connections.
   • A single client with very high omem: a slow consumer, possibly a forgotten MONITOR session, consuming a connection slot and large buffer memory.
   • Many connections from the same addr: a single application instance with an oversized pool.

5. Check for a thundering-herd trigger. Look for recent Redis restarts (INFO server | grep uptime_in_seconds), Sentinel failover events, or deployment events that could cause all application instances to reconnect simultaneously. A post-restart rejection burst that self-resolves is less urgent than a sustained pattern.

6. Correlate with application behavior. Check application error logs for connection failures. Count application instances and multiply by per-instance pool size to estimate expected connection count.

Metrics and signals to monitor

Fixes

Emergency triage: kill stale connections

If rejected_connections is actively incrementing and applications are failing, you can free slots immediately:

# Identify the most idle connections from CLIENT LIST output
redis-cli CLIENT LIST

# Kill a specific stale connection (disruptive to that client)
redis-cli CLIENT KILL <ip>:<port>

CLIENT KILL is disruptive. The killed client receives a connection error and must reconnect. Use it to free slots for critical connections, then address the root cause.

Raise maxclients (with ulimit prerequisite)

You can raise maxclients at runtime:

redis-cli CONFIG SET maxclients 20000

This only works if the OS file descriptor limit allows it. The safe formula: ulimit -n must be at least maxclients + 32. To raise the OS limit permanently on systemd-managed deployments:

# Edit the systemd override
systemctl edit redis

# Add under [Service]:
# LimitNOFILE=65535

Restart Redis for the limit to take effect, then verify:

cat /proc/$(pidof redis-server)/limits | grep "Max open files"

Persist the Redis config change so it survives restart:

redis-cli CONFIG REWRITE

Without CONFIG REWRITE, the maxclients change is lost on restart.

Fix connection leaks

If CLIENT LIST shows many connections with high idle time, the application is not closing connections properly. The root fix is in application code. As a server-side safety net:

# Set an idle timeout in seconds. Redis closes connections idle longer than this.
redis-cli CONFIG SET timeout 300

The default timeout is 0 (disabled). Setting it to 300 seconds means idle connections are cleaned up after 5 minutes. Timeout checks are approximate, not precise timers. This is a safety net, not a replacement for fixing the leak.

Tune connection pools

If each application instance opens more connections than necessary:

• Reduce pool size per instance.
• Ensure the application reuses connections rather than creating new ones per request.
• Calculate the expected total: app_instances * pool_size_per_instance + monitoring_connections + replica_connections. This should be below 80% of effective maxclients.
• Pipelining allows fewer connections to handle more load. A single connection with pipelining can outperform many idle connections.

Address connection churn

If CLIENT LIST shows age=0 on most connections and total_connections_received rate is very high, the application pool is misconfigured. It is creating and destroying connections on every request instead of reusing them. This looks like connection exhaustion but is actually a client-side pool configuration problem. Fix the pool to reuse connections with proper min-idle and max-active settings.

Managed service limits

If you are running a managed Redis service, the connection limit may be tier-dependent rather than 10,000. Azure Managed Redis, for example, uses SKU-based limits ranging from 15,000 to 200,000 connections. Check your provider documentation for the actual limit applicable to your tier.

Prevention

• Set a timeout. The default of 0 means idle connections persist forever. A timeout of 300 seconds provides a safety net against leaked connections.
• Monitor the true connection capacity ratio. Track (connected_clients + connected_slaves + cluster_connections) / maxclients and alert at 80%. This gives lead time before the cliff edge.
• Audit connection pool sizing regularly. Verify that app_instances * pool_size_per_instance plus internal connections stays below 80% of effective maxclients. Account for monitoring tools, Sentinel, and cluster bus connections.
• Verify the startup log after every restart. Check for the maxclients reduction warning. The log will show the effective limit if it was reduced below your configured value.
• Monitor total_connections_received rate. High churn indicates a client-side pool misconfiguration that stresses the event loop even when connected_clients is below the ceiling.
• Ensure LimitNOFILE is adequate. For any maxclients value, the OS file descriptor limit must be at least maxclients + 32. Make this part of your deployment template, not a post-incident fix.

How Netdata helps

• Per-second rejected_connections rate. Because rejected_connections is cumulative, Netdata computes the rate of change automatically. Any nonzero rate is immediately visible without manual sampling.
• Connection capacity ratio. Netdata correlates connected_clients against maxclients, surfacing the ratio rather than just the raw count. This provides lead time before the ceiling is hit.
• Connection churn detection. The total_connections_received rate alongside a stable connected_clients count reveals rapid connect/disconnect cycling before it cascades into rejection.
• Anomaly flags on connection patterns. ML-based anomaly detection catches unexpected connection spikes (new deployment, pool misconfiguration, retry storm) before the maxclients ceiling is reached.
• Correlation across signals. When rejected_connections starts incrementing, Netdata dashboards let you correlate timing with connected_clients trends, instantaneous_ops_per_sec changes, and application-level error rates to identify whether the cause is a retry storm, a deployment event, or a genuine leak.

Netdata’s Redis monitoring with Netdata brings these signals together with per-second metrics and ML anomaly detection.

Related guides

• How Redis actually works in production: a mental model for operators
• Redis NOAUTH / WRONGPASS authentication failures: ACL LOG and credential drift
• Redis aof_last_write_status:err: AOF write failures and recovery
• Redis appendfsync always latency: durability vs throughput trade-offs
• Redis big keys: finding the giant key that blocks the event loop
• Redis blocked_clients growing: dead consumers vs healthy queues
• Redis BUSY Redis is busy running a script: blocking Lua and how to recover
• Redis Can’t save in background: fork: Cannot allocate memory - diagnosis and fix
• Redis client output buffer overflow: slow consumers and client-output-buffer-limit
• Redis cluster bus port blocked: the port+10000 firewall gotcha
• Redis cluster_slots_pfail > 0: impending node failure in a cluster
• Redis CLUSTERDOWN / cluster_state:fail: slot coverage and recovery