Redis Hash Tag Tester

Paste the keys you want to use in a single command. This says whether they all hash to one slot, and if not, what to change. A multi-key command whose keys span slots is rejected, whatever nodes those slots happen to live on.

Paste below, or drop a file anywhere on this panel

Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.

The answer appears here

Paste on the left and press Check. Nothing leaves this tab.

Examples

Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.

CROSSSLOT

The command will be rejected, and what to change so it is not

cart:1000
cart:1000:items
cart:1000:total

Co-located by design

A shared tag guarantees these stay together across any resharding

{cart:1000}
{cart:1000}:items
{cart:1000}:total

Common mistakes

These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.

  1. Relying on two untagged keys that happen to share a slot

    CRC16 has only 16,384 outputs, so collisions happen. The command works today and breaks the day somebody renames a key, with no warning.

    Instead:If co-location is a requirement rather than luck, make it a hash tag.

  2. Expecting CROSSSLOT to depend on which node the keys are on

    It is a slot check, not a node check. Two slots on the same node today still fail, because the answer has to survive a resharding that has not happened yet.

    Instead:Give the keys a shared tag, or issue one command per key.

  3. Tagging by operation instead of by entity

    A tag like `{batch1}` co-locates keys that only belong together briefly, and they stay clustered forever, producing a hot slot nothing can spread.

    Instead:Tag the thing the keys are about: the user, the tenant, the order.

CROSSSLOT is a slot check, not a node check

This is the distinction that makes the error confusing. Two keys can be on the same physical node today and still be rejected, because the answer has to remain correct after a resharding that Redis has not performed yet.

What requires one slot

MGET, MSET, MSETNX, DEL with several keys, SUNIONSTORE, ZUNIONSTORE, SMOVE, RENAME, BITOP, any Lua script declaring more than one key in KEYS, and every command inside a MULTI. All of them fail with CROSSSLOT Keys in request don't hash to the same slot if the keys span more than one.

Why not just fetch across nodes

Redis could route to several nodes and merge, and deliberately does not. A multi-key operation across nodes cannot be atomic, and a Lua script cannot be, so the guarantee people rely on would silently weaken. Refusing is the honest option, and it pushes the decision back to the key design where it belongs.

The accidental pass is the dangerous result

Two untagged keys can collide into the same slot by coincidence, because CRC16 has only 16,384 outputs. The command works, the test passes, and then somebody renames a key and it breaks in production. If co-location is a requirement rather than a happy accident, it has to be a hash tag.

Tag the entity, not the operation

The tag should be the thing the keys are about, usually a user or tenant or order id, so that everything belonging to that entity is co-located. Tagging by operation, for example {batch1}, moves the problem: the batch is over quickly and the keys stay clustered forever, which produces hot slots that no resharding can spread out.

What this cannot see

It cannot tell you whether the keys exist, how large they are, or whether concentrating them in one slot creates a hot spot. A tag that co-locates ten million keys makes them all one node's problem, and no error will ever mention that. It also does not apply to a standalone Redis, where every key is local and multi-key commands always work.