Redis can publish an event whenever a key changes, but the feature ships disabled. How do you turn Redis keyspace notifications on, and what do the individual flag characters in the notify-keyspace-events configuration value mean?

## What the feature does When enabled, Redis publishes a Pub/Sub message every time a key is affected by a command or removed by expiration or eviction. Clients subscribe with `SUBSCRIBE` or `PSUBSCRIBE` on the notification channels and receive those messages like any other Pub/Sub traffic. The events describe *that* something happened to a key; they never carry the value. ## The configuration string Everything is controlled by `notify-keyspace-events`, settable in redis.conf or at runtime with `CONFIG SET`. Its value is an unordered set of characters, and the empty string - the default - disables the feature entirely so it costs nothing on an instance that does not use it. The characters fall into two groups that must both be represented for anything to arrive. **Where events are published** - `K` - keyspace notifications, published to `__keyspace@<db>__:<keyname>`, with the event name as the message payload. - `E` - keyevent notifications, published to `__keyevent@<db>__:<eventname>`, with the key name as the message payload. **Which events are generated** - `g` generic commands that are not type specific: DEL, EXPIRE, RENAME, PERSIST and similar. - `$` string commands, `l` list commands, `s` set commands, `h` hash commands, `z` sorted-set commands, `t` stream commands, `d` module key-type events. - `x` expired - fired when a key is removed because its TTL elapsed. - `e` evicted - fired when a key is removed by maxmemory eviction. - `m` key-miss - fired when a read finds no key (added in Redis 6.0); deliberately excluded from `A` because it is very noisy. - `n` new-key events (Redis 7.0), also excluded from `A`. - `A` - shorthand for the whole set `g$lshzxetd`. A value such as `"gxE"` means: generate generic and expired events, deliver them on keyevent channels. A value of `"gx"` alone generates nothing observable, because neither `K` nor `E` is present - Redis accepts it silently and the subscriber sees nothing, which is the single most common support question about this feature. ## Cost and blast radius Enabling classes is not free. Every matching command does extra work to build and publish a message, and Pub/Sub fanout is performed on the same thread that executes commands. On a busy instance `"KEA"` means two published messages for every write, and with pattern subscribers matching every channel the fanout cost grows with the number of subscribers. In Redis Cluster, keyspace notifications use ordinary (non-sharded) Pub/Sub, so messages propagate across the cluster bus to all nodes rather than staying local to the shard - a genuine bandwidth consideration on chatty instances. The practical rule is to enable the narrowest set that satisfies the use case. A cache-invalidation listener that only cares about expiry needs `"Ex"`, not `"KEA"`. ## Operational notes - The setting is dynamic: `CONFIG SET notify-keyspace-events Ex` takes effect immediately, and `CONFIG GET` reads back a normalised string. - Because the flags are a set, order does not matter, but the string is case sensitive: `K` and `E` are not `k` and `e`. - The database number is baked into the channel name, so a subscriber must know which database it is watching, or use a pattern such as `__keyevent@*__:expired`. - Events are published even if no client is subscribed; the flags, not the audience, decide whether the work is done.