CROSSSLOT Keys in request don't hash to the same slot

What it means

Redis Cluster spreads keys over 16,384 hash slots, and a slot is the unit it moves between nodes. So that a command never needs data from two places, every command, transaction (MULTI/EXEC) and script that names more than one key must name keys from one slot. Otherwise the node refuses it with CROSSSLOT and nothing runs.

The rule is about slots, not nodes. In the test below, user:1 (slot 10778) and user:2 (slot 6777) were both on the same node and MGET user:1 user:2 still failed.

Only cluster mode has this rule: a standalone Redis server never returns CROSSSLOT.

Common causes

1. Multi-key commands on unrelated keys: MSET, MGET, DEL, UNLINK, EXISTS, SUNION, SINTERSTORE, ZUNIONSTORE, RENAME, BLPOP with several lists…
2. Transactions whose commands touch keys in different slots. Each command is queued with QUEUED; the EXEC fails with CROSSSLOT and none of them runs.
3. Lua scripts and functions given keys in different slots in KEYS.
4. Code written for a single server and moved to a cluster: Redis Cluster, ElastiCache with cluster mode enabled (ElastiCache Serverless caches always run with cluster mode on), or Redis Cloud with the OSS Cluster API.

How to fix it

Put related keys in one slot with a hash tag

If a key contains {…}, only the part between the first { and the next } is hashed. Keys that share that part share a slot:

{user:1}:profile   → slot 10778
{user:1}:cart      → slot 10778
user:1             → slot 10778

Check with CLUSTER KEYSLOT:

redis-cli CLUSTER KEYSLOT '{user:1}:profile'

Group by what you read and write together: one user, one order, one tenant. Don’t give every key the same tag: a slot lives on one node, so all those keys and their traffic end up on one server.

Changing key names means migrating the data: write under the new names and read both until the old keys are gone.

Or send one command per key

MGET a b c becomes three GETs, sent together in a pipeline so it costs one round trip (a cluster client sends each one to the right node). DEL of many keys works the same way: one DEL (or UNLINK) per key, pipelined. Some cluster clients can do this splitting for you; check your library’s documentation. Either way it’s no longer atomic: another client can see some keys changed and others not yet.

Keep transactions and scripts to one slot

Pass every key a script uses in KEYS, and make them share a hash tag. A script that reaches a key on another node fails with ERR Script attempted to access a non local key in a cluster node. If the keys can’t share a slot, the work can’t be atomic in a cluster: split it, and decide what happens if one part fails.

On Redis Cloud

Redis Cloud’s default (proxied) endpoint runs MGET, MSET and similar commands across slots for you, its documentation says, but transactions, scripts, RENAME and commands such as SUNION still need their keys in one slot.

Reproduce it

A temporary Redis 8.10.2 container running a three-node cluster (slots 0–5460 on port 6381, 5461–10922 on 6382, 10923–16383 on 6383; see MOVED for the setup). foo is in slot 12182 and bar in 5061, on different nodes; user:1 and user:2 are both on 6382:

$ redis-cli -p 6381 MSET foo 1 bar 2
(error) CROSSSLOT Keys in request don't hash to the same slot
$ redis-cli -p 6382 MGET user:1 user:2
(error) CROSSSLOT Keys in request don't hash to the same slot
$ redis-cli -p 6382 DEL user:1 user:2
(error) CROSSSLOT Keys in request don't hash to the same slot

EXISTS, SUNION, RENAME and an EVAL given both keys in KEYS failed the same way. A transaction queued both writes and failed at EXEC; afterwards EXISTS user:1 returned (integer) 0:

OK
QUEUED
QUEUED
(error) CROSSSLOT Keys in request don't hash to the same slot

With a hash tag:

$ redis-cli -p 6382 MSET '{user:1}:profile' a '{user:1}:cart' b
OK
$ redis-cli -p 6382 MGET '{user:1}:profile' '{user:1}:cart'
1) "a"
2) "b"

A script given user:1 that read foo, on another node:

(error) ERR Script attempted to access a non local key in a cluster node script: a7dcbe4472943373859c0719366b7de09b8ad310, on @user_script:1.

A temporary Valkey 8.1.10 cluster gave the same CROSSSLOT message for MSET and for the transaction, and the same script error.

In Inlet

Inlet connects to one node and doesn’t support cluster mode yet, so on a cluster node a multi-key command with keys in different slots gets this error in Inlet as in any client. Inlet shows the message and links it to this page. Use CLUSTER KEYSLOT in a query tab to check where keys fall.