Clients vs maxclients %, gauge

​

At a glance

Connection-pool saturation expressed as a percentage: connected_clients / maxclients. When that ratio reaches 100% Redis stops accepting new connections and returns ERR max number of clients reached, which immediately drops every downstream service that needs a fresh connection (a restarting app pod, a cron worker, a new web node scaling in). For a platform team this is “how close am I to the moment Redis refuses to talk to anyone new?” A healthy steady state sits well under 50%; sustained readings above 90% mean a connection leak, an undersized maxclients, or a thundering herd of short-lived clients.

​

Calculation

saturation_pct = (connected_clients / maxclients) * 100

• maxclients is not always what you set. Redis reserves around 32 file descriptors for its own use (cluster bus, replicas, persistence). If the OS ulimit -n is lower than maxclients + 32, Redis silently lowers the effective maxclients at start-up and logs a warning. The card reads the effective value Redis reports through CONFIG GET maxclients, not the value in redis.conf, so the percentage reflects reality.
• Replica and cluster-bus connections count toward connected_clients on some versions. The engine uses the headline connected_clients from INFO clients as Redis reports it; for cluster nodes this can include a handful of internal links, which is why the denominator matters more than a couple of connections.
• Managed services cap maxclients for you. On ElastiCache and MemoryDB the maxclients value is fixed per node type (for example 65,000 on most node sizes) and cannot be raised through CONFIG SET. The card still reads the live effective value so the gauge is accurate even when you cannot change the ceiling.

​

Worked example

1. Is the denominator wrong (too-small maxclients)? No, 65,000 is the node ceiling.
2. Is this real demand or a leak? The climb from 41,000 to 58,900 in one hour with no matching traffic increase is the tell. A connection leak: the application opens a connection per request and never returns it to a pool, so connections accumulate until idle ones are reaped (or never are, if timeout 0 is set).
3. What happens at 100%? New web nodes scaling in for the peak cannot connect and crash-loop, which paradoxically makes the team scale out further, opening even more connections and accelerating the climb.

Cost framing for the leaking instance:
  - Connections climbing ~300/min toward the 65,000 cap
  - At current rate the cap is reached in ~20 minutes
  - At the cap: every new pod and cron worker gets
    "ERR max number of clients reached"
  - Mitigation now: deploy the pooled client (PgBouncer-equivalent
    for Redis is a client-side pool), or set a sane `timeout` so
    idle connections are reaped, or CONFIG SET maxclients higher
    (self-hosted only) to buy time

1. The percentage hides the headroom in connection count. 91% of 65,000 still leaves 6,100 connections, but at a 300/min climb that headroom is 20 minutes, not comfort. Always read the gauge and the slope.
2. The fix is almost always client-side. Raising maxclients treats the symptom. A connection pool or a non-zero idle timeout treats the cause. Pair with Connected Clients to watch the raw count after the fix.
3. Rejected connections are the lagging confirmation. Once you cross 100%, Rejected Connections (24h) starts incrementing. If this gauge is green but rejections are non-zero, you had a transient spike that the 1-minute smoothing missed.

​

Sibling cards

​

Reconciling against the source

redis-cli INFO clients returns connected_clients, blocked_clients, and cluster_connections. This is the numerator straight from the source. redis-cli CONFIG GET maxclients returns the effective ceiling (the denominator). Compare it against the value in redis.conf; if they differ, the OS file-descriptor limit clipped it. redis-cli CLIENT LIST enumerates every open connection with its idle time, address, and last command, the definitive way to find a leak (look for thousands of connections with growing idle and cmd=NULL). redis-cli INFO stats exposes total_connections_received and rejected_connections for the historical view.

ElastiCache / MemoryDB: CloudWatch metric CurrConnections is the numerator; the maxclients ceiling is fixed per node type and documented in the AWS node-type reference. Divide to reproduce the gauge. Azure Cache for Redis: the Connected Clients metric in Azure Monitor; the connection limit is tier-dependent. Redis Cloud (Redis Enterprise): the conns metric in the database metrics view; the limit is set per database subscription.

​

Known limitations / FAQs

​

Tracked live in Vortex IQ Nerve Centre