go-redis/redis · critical

redis: all sentinels specified in configuration are unreacha

Error message

redis: all sentinels specified in configuration are unreachable

What it means

Returned by the sentinel failover client when every Sentinel in SentinelAddrs was contacted for replica discovery and none responded successfully (sentinelReachable stayed false). Unlike a partial failure (which returns nil/empty addrs to retry master), this means no Sentinel could be reached at all during a replica lookup cycle.

Source

Thrown at sentinel.go:1132

				c.opt.MasterName, err)
			continue
		}
		sentinelReachable = true
		addrs := parseReplicaAddrs(replicas, useDisconnected)
		if len(addrs) == 0 {
			continue
		}
		// Push working sentinel to the top.
		c.sentinelAddrs[0], c.sentinelAddrs[i] = c.sentinelAddrs[i], c.sentinelAddrs[0]
		c.setSentinel(ctx, sentinel)

		return addrs, nil
	}

	if sentinelReachable {
		return nil, nil
	}
	return nil, errors.New("redis: all sentinels specified in configuration are unreachable")
}

func (c *sentinelFailover) getMasterAddr(ctx context.Context, sentinel *SentinelClient) (string, error) {
	addr, err := sentinel.GetMasterAddrByName(ctx, c.opt.MasterName).Result()
	if err != nil {
		return "", err
	}
	return net.JoinHostPort(addr[0], addr[1]), nil
}

func (c *sentinelFailover) getReplicaAddrs(ctx context.Context, sentinel *SentinelClient) ([]string, error) {
	addrs, err := sentinel.Replicas(ctx, c.opt.MasterName).Result()
	if err != nil {
		internal.Logger.Printf(ctx, "sentinel: Replicas name=%q failed: %s",
			c.opt.MasterName, err)
		return nil, err
	}
	return parseReplicaAddrs(addrs, false), nil

View on GitHub (pinned to 36d97525cd)

Solutions

  1. Verify network reachability and correct ports for every Sentinel address (redis-cli -p <sentinelPort> ping).
  2. Check that Sentinel processes are running on the configured hosts.
  3. Confirm auth/TLS settings in SentinelOptions match each Sentinel's configuration.
  4. Add more Sentinel addresses for redundancy and tune the failover client's retry/backoff so it survives transient partitions.

Example fix

// before
client := redis.NewFailoverClient(&redis.FailoverOptions{
    MasterName:    "mymaster",
    SentinelAddrs: []string{"sentinel-1:26379"}, // down/unreachable
})

// after — multiple reachable sentinels + retries
client := redis.NewFailoverClient(&redis.FailoverOptions{
    MasterName:    "mymaster",
    SentinelAddrs: []string{"sentinel-1:26379", "sentinel-2:26379", "sentinel-3:26379"},
    MaxRetries:    5,
})
Defensive patterns

Strategy: retry

Validate before calling

func pingSentinels(addrs []string) error {
    var lastErr error
    for _, a := range addrs {
        c := redis.NewClient(&redis.Options{Addr: a})
        if err := c.Ping(context.Background()).Err(); err != nil {
            lastErr = err
            continue
        }
        _ = c.Close()
        return nil
    }
    return fmt.Errorf("no sentinel reachable: %w", lastErr)
}

Try / catch

addr, err := failoverClient.MasterAddr(ctx)
if err != nil && err.Error() == "redis: all sentinels specified in configuration are unreachable" {
    // total sentinel outage; back off and retry, or fail over to a static master
}

Prevention

When it happens

Trigger: All Sentinel processes are down or unreachable (network, host failure). Wrong Sentinel ports/addresses in config. Firewall or auth blocking all Sentinel connections. A transient total network partition during a replica query.

Common situations: Sentinel host outage or maintenance. Network partition isolating the app from all Sentinels. Misconfigured Sentinel ports after an infra migration. TLS or auth mismatch on every Sentinel.

Related errors


AI-assisted analysis of go-redis/redis@36d97525cd (2026-08-06). Data as JSON: /data/errors/3b7723d9ac4e785b.json. Report an issue: GitHub.