Every key in one slot
A constant hash tag puts the whole keyspace on a single node
{app}:user:1
{app}:user:2
{app}:user:3
{app}:user:4
{app}:user:5
{app}:user:6Paste key names, one per line. Redis accepts almost any byte sequence as a key, so nothing here is about validity: it is about names that work in a shell, in a log, and on a cluster.
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.
Nothing else to flag.
No formatting problems, and nothing the rules object to. Worth remembering what that covers: this reads the file you pasted, not the account or cluster it will be applied to.
No finding matches that filter.
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.
A constant hash tag puts the whole keyspace on a single node
{app}:user:1
{app}:user:2
{app}:user:3
{app}:user:4
{app}:user:5
{app}:user:6Legal, and painful in every shell and every log
user:1 a key with spaces session:abc
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
It forces the whole keyspace into one slot on one node, so the cluster cannot balance.
Instead:Tag by the group that must stay together, such as a tenant id.
A newline or a null byte produces a key nobody can see in any diagnostic.
Instead:Strip control characters, or hash the variable part.
An empty brace pair is not a tag, and neither is an unclosed brace. The whole key is hashed instead.
Instead:Put a real value between the braces.
Prefix patterns written for one convention silently miss the others.
Instead:Pick one separator and use it everywhere.
A key can contain a newline, a space or a null byte and Redis will store and return it perfectly. Everything else in your stack will not cope as well.
A key with a trailing newline looks identical to one without in redis-cli output, in MONITOR, in SLOWLOG and in your logs. It stores and retrieves correctly, so the bug is a lookup that fails for no visible reason, and a difference nobody can see is one nobody can fix.
Only the text between the first brace and the first closing brace after it is hashed. That is what makes multi-key commands possible on a cluster. Using the same tag for every key puts the entire keyspace on one node, so the cluster cannot balance and one node carries all the traffic.
An empty pair is not a tag. An unclosed brace is not a tag. Only the first brace, paired with the first closing brace after it, counts. A key that looks tagged may not be, and it will land in a different slot than the one you intended.
The name is stored in full, in memory, for every key, and it is copied into every reply and every log line. At tens of millions of keys the names alone become a measurable fraction of the dataset. The limit is 512 MB, so this is a cost question rather than a validity one.
A SCAN pattern written for one convention silently misses keys following another. Pick one, conventionally the colon, and use it everywhere.