Redis CLUSTERDOWN: the cluster is down

Fix Redis CLUSTERDOWN by restoring slot coverage, fixing a failed slot owner, and understanding the cluster-require-full-coverage setting.

advanceddebuggingredisclusterdatabase

Symptoms

CLUSTERDOWN The cluster is down
All writes fail even though some nodes are healthy
Only a subset of keys is inaccessible

Possible causes

A master holding slots is down and no replica was promoted
Slot ranges are uncovered after a failed reshard
cluster-require-full-coverage is on and one slot range is missing
A node is misconfigured with the wrong slot assignment

Diagnosis steps

Inspect cluster slot coverage

redis-cli -c CLUSTER INFO | grep cluster_slots

Interpretation

Assigned slots below the total 16384 mean uncovered ranges cause CLUSTERDOWN under full-coverage mode.

Map slots to nodes and find gaps

redis-cli -c CLUSTER SLOTS

Interpretation

Missing ranges identify which node needs recovery or reassignment.

Check node states

redis-cli -c CLUSTER NODES

Interpretation

fail entries and no promoted replica explain why slots lost their owner.

Root cause

A Redis Cluster needs all 16384 slots assigned and owned. When cluster-require-full-coverage is enabled, any gap in ownership makes the whole cluster report CLUSTERDOWN, refusing commands even on keys whose slots are still served. A failed master without promotion, or a botched reshard, leaves such a gap.

Fix

Restore slot ownership: bring the failed node back or promote a replica with CLUSTER FAILOVER, then reassign orphaned slots with CLUSTER ADDSLOTS or fix them via reshard. If a short outage is acceptable, temporarily set cluster-require-full-coverage no so healthy slots keep serving while you repair, then re-enable it.

Verify the fix

Run CLUSTER INFO; cluster_slots_assigned equals 16384 and cluster_state is ok, with application commands on all keys succeeding again.

Symptoms

Every command returns CLUSTERDOWN The cluster is down, including against keys whose slots still have a healthy owner. Some nodes are up and connected.

Diagnosis

Find uncovered slots and their former owners:

redis-cli -c CLUSTER INFO | grep -E 'cluster_state|cluster_slots_assigned'
redis-cli -c CLUSTER SLOTS
redis-cli -c CLUSTER NODES

Assigned slots below 16384 reveal the gap.

Fix

Promote a replica or reassign orphaned slots:

redis-cli -c -h failed-master-replica CLUSTER FAILOVER
redis-cli -c CLUSTER ADDSLOTS 8000 8001 8002

Temporarily relax coverage to keep healthy slots serving:

redis-cli config set cluster-require-full-coverage no

Verification

CLUSTER INFO shows cluster_state:ok with all 16384 slots assigned, and reads and writes on every key range succeed.

Full Coverage as a Trade-off

cluster-require-full-coverage is a deliberate trade: with it on, the cluster prefers consistency over availability, refusing all commands when any slot is unowned so clients never see partial data. With it off, healthy slots keep serving during a repair, which suits systems that can tolerate a brief window where one key range is unavailable. Neither setting fixes a lost slot; both only change how the outage presents. The durable fix is restoring ownership through failover or ADDSLOTS, and monitoring cluster_slots_assigned so a gap is detected before it escalates to a full CLUSTERDOWN.