Introduction

In Redis Cluster, slot ranges usually appear only on master nodes that currently own parts of the keyspace. So when CLUSTER NODES shows a node line without slot information, the meaning depends on the node's role and cluster state: it may be normal, or it may signal an incomplete or unhealthy cluster configuration.

What Slot Information Normally Means

Redis Cluster divides the keyspace into 16384 hash slots. Healthy masters own one or more slot ranges, and those slot assignments appear at the end of the node line.

Example:

07c37dfe... 127.0.0.1:7000@17000 master - 0 0 1 connected 0-5460
3c3a1c7b... 127.0.0.1:7001@17001 master - 0 0 2 connected 5461-10922
1c1f9d2a... 127.0.0.1:7002@17002 master - 0 0 3 connected 10923-16383

Those final ranges tell you exactly which master owns which slots.

When Missing Slot Information Is Normal

There are a few normal cases where a node line has no slots listed.

Replicas usually have no slot ranges

Replicas mirror a master and do not own slots directly, so a replica line often looks like this:

9f0b2d1e... 127.0.0.1:7003@17003 slave 07c37dfe... 0 0 4 connected

That is normal. The replica follows a master that owns the slots.

A newly added master may not own slots yet

If you add a node to the cluster but have not assigned or moved slots to it, it can appear as a master with no slot ranges. That means it exists in the cluster but is not serving part of the keyspace yet.

A drained master can temporarily have no slots

During resharding, slots may be moved away from a master. For a while, that master can appear with no slots until it is removed or assigned new ones.

When Missing Slots Are a Problem

A master without slots is suspicious when the cluster is supposed to be stable and fully serving the keyspace. It can indicate:

• incomplete resharding
• a node added but never assigned slots
• failed cluster maintenance
• slot coverage problems

If the cluster is missing slot ownership overall, clients may start seeing MOVED, ASK, or cluster-state errors because the keyspace is not fully covered by healthy masters.

Check the Cluster State, Not Just One Line

CLUSTER NODES is useful, but it should not be read in isolation. Pair it with:

CLUSTER INFO

and operational checks such as:

• whether cluster_state is ok
• whether all 16384 slots are assigned
• whether any nodes are marked fail or handshake

If your tooling allows it, redis-cli --cluster check is also a strong sanity check because it validates slot coverage and reports cluster inconsistencies more directly than raw node output.

Interpreting a Master with No Slots

A master line without slots means one of two broad things:

• intentional transitional state
• configuration problem

It is intentional if you just added the node, just drained it, or are actively resharding. It is a problem if you expected the cluster to be steady and every master to be serving a portion of the keyspace.

Operational context is what decides whether the output is normal.

Common Pitfalls

The most common mistake is assuming every node in CLUSTER NODES should show slot ranges. Replicas normally do not. Another is seeing a master with no slots and treating that as automatically broken even when the node was just added for future resharding. The opposite mistake also happens: teams ignore slotless masters in a supposedly stable cluster and miss that the cluster was never fully balanced or fully assigned after maintenance.

Summary

• Slot ranges usually appear only on masters that currently own part of the keyspace.
• Replicas normally have no slot information, and that is expected.
• A master without slots can be normal during add-node or resharding workflows.
• In a stable cluster, a master with no slots may indicate incomplete configuration or slot coverage issues.
• Use CLUSTER INFO and cluster-check tooling alongside CLUSTER NODES before deciding whether missing slots are normal or a problem.