redis/jedis · critical · JedisConnectionException

All sentinels down, cannot determine where

Error message

All sentinels down, cannot determine where ${masterName} is running.

What it means

SentineledConnectionProvider.initSentinels() failed to connect to every configured sentinel, so it cannot discover where the master is running and throws JedisConnectionException. Unlike the 'not monitored' case, no sentinel was reachable at all (sentinelAvailable is false).

Solutions

  1. Verify each sentinel endpoint with redis-cli -h <host> -p 26379 ping and fix the endpoints list.
  2. Check network/firewall rules (security groups, NetworkPolicy) allow the client to reach sentinel ports.
  3. Restart or replace the sentinel processes and update the client's sentinel set with current addresses.
  4. Confirm the client is using the correct environment's sentinel hosts (not decommissioned ones).

Example fix

// before
Set<HostAndPort> sentinels = Set.of(new HostAndPort("10.0.0.5", 26379)); // host gone
// after
Set<HostAndPort> sentinels = Set.of(
  new HostAndPort("sentinel-0.svc", 26379),
  new HostAndPort("sentinel-1.svc", 26379),
  new HostAndPort("sentinel-2.svc", 26379));
Defensive patterns

Strategy: retry

Validate before calling

for (HostAndPort hp : sentinels) {
  try (Jedis s = new Jedis(hp.getHost(), hp.getPort(), 2000)) { s.ping(); }
  catch (Exception e) { throw new IllegalStateException("Sentinel unreachable: " + hp, e); }
}

Try / catch

try {
  pool = new JedisSentinelPool(masterName, sentinels, clientConfig);
} catch (JedisConnectionException e) {
  log.error("All sentinels down; retrying with backoff", e);
  // retry with exponential backoff, then alert / fall back to last-known master address
}

Prevention

When it happens

Trigger: Building a sentinel-based client where all sentinel HostAndPort endpoints are unreachable: wrong ports, hosts down, firewall/network partition, or sentinels bound to interfaces not reachable from the client.

Common situations: Kubernetes/Docker network misconfiguration so the client cannot reach sentinel pods; stale sentinel endpoints after a deployment; firewall or security-group blocking port 26379; sentinels crashed and DNS still resolves old addresses.

Understand the failure class

Background: ECONNREFUSED and "connection refused" / "could not connect to server" errors: what they mean and how to fix them — this error's family across 44 libraries.

Related errors


AI-assisted analysis of redis/jedis@6dac31d4c2 (2026-09-08). Data as JSON: /api/errors/ee3cccbd23bbd3df. Report an issue: GitHub.

Appendix: source

Thrown at src/main/java/redis/clients/jedis/providers/SentineledConnectionProvider.java:286

        }

        master = toHostAndPort(masterAddr);
        LOG.debug("Redis master reported at {}.", master);
        break;
      } catch (JedisException e) {
        // resolves #1036, it should handle JedisException there's another chance
        // of raising JedisDataException
        LOG.warn("Could not get master address from {}.", sentinel, e);
      }
    }

    if (master == null) {
      if (sentinelAvailable) {
        // can connect to sentinel, but master name seems to not monitored
        throw new JedisException(
            "Can connect to sentinel, but " + masterName + " seems to be not monitored.");
      } else {
        throw new JedisConnectionException(
            "All sentinels down, cannot determine where " + masterName + " is running.");
      }
    }

    LOG.info("Redis master running at {}. Starting sentinel listeners...", master);

    for (HostAndPort sentinel : sentinels) {

      SentinelListener listener = new SentinelListener(sentinel);
      // whether SentinelListener threads are alive or not, process can be stopped
      listener.setDaemon(true);
      sentinelListeners.add(listener);
      listener.start();
    }

    return master;
  }

View on GitHub (pinned to 6dac31d4c2)