The Rejected Connections metric tracks the number of client connections that were denied by the Redis server. A connection rejection typically happens when the server is unable to accept new client connections due to resource constraints, configuration limits, or network issues.
Impact
When Redis begins rejecting connections, applications that rely on it may experience:
-
Delays or failures in data access
-
Increased application errors or timeouts
-
User-facing service disruptions
-
Data loss risks (in real-time systems)
Even short bursts of rejected connections can signal underlying instability that may escalate if not addressed promptly.
Possible causes
1. Connection Limit Reached (maxclients).
Redis enforces a maximum number of simultaneous client connections defined by the maxclients configuration parameter.
Problem identification:
Identify the maximum number of simultaneous client connections configured and compare it with your user connections demand.
- Run INFO clients from the Redis CLI and check connected_clients.
- Look at maxclients in redis.conf or run CONFIG GET maxclients.
- Check Redis logs manually for “max number of clients reached” messages.
- Use OS monitoring tools to watch for connection spikes.Correlate rejection times with application errors or logs.
Recommended action :
-
Raise the
maxclientslimit if system resources permit. -
Enforce connection pooling on the application side.
-
Detect and close idle or orphaned sessions.
2. Application Creating Too Many Redis Connections.
Bad application design can flood Redis with connections if it creates a new one for every command or transaction.
Problem identification:
Analyze the application code to determine how Redis connections are handled.
-
Use Redis CLI to sample
CLIENT LISTand inspect connection patterns. -
Observe Redis logs for large bursts of connections/disconnections.
-
Monitor network traffic to Redis manually (e.g., with Wireshark or
netstat).
With AimBetter, you can quickly identify abnormal patterns, such as frequent short-lived connections or client spikes, by analyzing metrics like Connected Clients, Commands Processed, and Rejected Connections over time. You can also correlate these trends with application changes or deployments using timeline views and server configuration tracking to pinpoint the root cause faster.
Recommended action :
- Use Reliable Hardware (SSD over HDD). Prefer enterprise-grade SSDs for Redis workloads. Avoid cheap or low-end flash storage, especially for write-intensive workloads. Use RAID (e.g. RAID 10) for performance + redundancy.
- Enable Filesystem Journaling and Use a Stable FS. Use modern, journaled filesystems.
- Mount with safe options: defaults,noatime,nodiratime. Consider fsck on reboot to auto-fix errors.
- Monitor Disk Health and I/O Load Continuously with tools like AimBetter.
3- Network Issues or Unstable Connectivity.
Unstable network conditions can cause failed or half-open Redis connections, consuming resources and leading to rejections.
Problem identification:
Use a network performance monitoring tool to measure network latency, throughput, and packet loss, and check for errors and hardware.
-
Use
ping,traceroute, ormtrto diagnose latency or packet loss. -
Manually inspect application logs for connection retries.
-
Check OS-level logs for TCP connection issues.
-
Investigate firewall or DNS issues via syslog and routing configs.
With AimBetter, you can analyze network-related rejected connections by correlating spikes in the Rejected Connections metric with network latency or packet loss shown in the Network Tab. Additionally, you can use the Change Tracker to identify recent DNS, firewall, or routing changes that may be affecting Redis connectivity.
Recommended action :
-
Set a limit on the max number of connections per application instance.
-
Profile application behavior under load to detect abnormal connection usage.
-
Consider using persistent connections with keepalive for frequent-access patterns.
-
Use AimBetter’s timeline view to compare app deployment times with connection spikes.
