
# Redis keyspace notifications

Monitor changes to Redis keys and values in real time

Keyspace notifications allow clients to subscribe to Pub/Sub channels in order to receive events affecting the Redis data set in some way.

Examples of events that can be received are:

*   All the commands affecting a given key.
*   All the keys receiving an LPUSH operation.
*   All the keys expiring in the database 0.

Note: Redis Pub/Sub is _fire and forget_; that is, if your Pub/Sub client disconnects, and reconnects later, all the events delivered during the time the client was disconnected are lost.

### Type of events

Keyspace notifications are implemented by sending two distinct types of events for every operation affecting the Redis data space. For instance a [`DEL`](/docs/latest/commands/del/) operation targeting the key named `mykey` in database `0` will trigger the delivering of two messages, exactly equivalent to the following two [`PUBLISH`](/docs/latest/commands/publish/) commands:

```
PUBLISH __keyspace@0__:mykey del
PUBLISH __keyevent@0__:del mykey
```

The first channel listens to all the events targeting the key `mykey` and the other channel listens only to `del` operation events on the key `mykey`

The first kind of event, with `keyspace` prefix in the channel is called a **Key-space notification**, while the second, with the `keyevent` prefix, is called a **Key-event notification**.

In the previous example a `del` event was generated for the key `mykey` resulting in two messages:

*   The Key-space channel receives as message the name of the event.
*   The Key-event channel receives as message the name of the key.

It is possible to enable only one kind of notification in order to deliver just the subset of events we are interested in.

### Configuration

By default keyspace event notifications are disabled because while not very sensible the feature uses some CPU power. Notifications are enabled using the `notify-keyspace-events` of redis.conf or via the **CONFIG SET**.

Setting the parameter to the empty string disables notifications. In order to enable the feature a non-empty string is used, composed of multiple characters, where every character has a special meaning according to the following table:

```
K     Keyspace events, published with __keyspace@<db>__ prefix.
E     Keyevent events, published with __keyevent@<db>__ prefix.
g     Generic commands (non-type specific) like DEL, EXPIRE, RENAME, ...
$     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 events (events generated every time a key expires)
e     Evicted events (events generated when a key is evicted for maxmemory)
m     Key miss events generated when a key that doesn't exist is accessed (Note: not included in the 'A' class)
n     New key events generated whenever a new key is created (Note: not included in the 'A' class)
o     Overwritten events generated every time a key is overwritten (Note: not included in the 'A' class)
c     Type-changed events generated every time a key's type changes (Note: not included in the 'A' class)
A     Alias for "g$lshztdxe", so that the "AKE" string means all the events except "m", "n", "o" and "c".
```

At least `K` or `E` should be present in the string, otherwise no event will be delivered regardless of the rest of the string.

For instance to enable just Key-space events for lists, the configuration parameter must be set to `Kl`, and so forth.

You can use the string `KEA` to enable most types of events.

### Events generated by different commands

Different commands generate different kind of events according to the following list.

*   [`APPEND`](/docs/latest/commands/append/) generates an `append` event.
*   [`COPY`](/docs/latest/commands/copy/) generates a `copy_to` event.
*   [`DEL`](/docs/latest/commands/del/) generates a `del` event for every deleted key.
*   [`EXPIRE`](/docs/latest/commands/expire/) and all its variants ([`PEXPIRE`](/docs/latest/commands/pexpire/), [`EXPIREAT`](/docs/latest/commands/expireat/), [`PEXPIREAT`](/docs/latest/commands/pexpireat/)) generate an `expire` event when called with a positive timeout (or a future timestamp). Note that when these commands are called with a negative timeout value or timestamp in the past, the key is deleted and only a `del` event is generated instead.
*   [`HDEL`](/docs/latest/commands/hdel/) generates a single `hdel` event, and an additional `del` event if the resulting hash is empty and the key is removed.
*   [`HEXPIRE`](/docs/latest/commands/hexpire/) and all its variants ([`HEXPIREAT`](/docs/latest/commands/hpexpireat/), [`HPEXPIRE`](/docs/latest/commands/hpexpire/), [`HPEXPIREAT`](/docs/latest/commands/hpexpireat/)) generate `hexpired` events. Furthermore, `hexpired` events are generated when fields expire.
*   [`HINCRBYFLOAT`](/docs/latest/commands/hincrbyfloat/) generates an `hincrbyfloat` event.
*   [`HINCRBY`](/docs/latest/commands/hincrby/) generates an `hincrby` event.
*   [`HPERSIST`](/docs/latest/commands/hpersist/) generates an `hpersist` event.
*   [`HSET`](/docs/latest/commands/hset/), [`HSETNX`](/docs/latest/commands/hsetnx/) and [`HMSET`](/docs/latest/commands/hmset/) all generate a single `hset` event.
*   [`INCRBYFLOAT`](/docs/latest/commands/incrbyfloat/) generates an `incrbyfloat` events.
*   [`INCR`](/docs/latest/commands/incr/), [`DECR`](/docs/latest/commands/decr/), [`INCRBY`](/docs/latest/commands/incrby/), [`DECRBY`](/docs/latest/commands/decrby/) commands all generate `incrby` events.
*   [`LINSERT`](/docs/latest/commands/linsert/) generates an `linsert` event.
*   [`LMOVE`](/docs/latest/commands/lmove/) and [`BLMOVE`](/docs/latest/commands/blmove/) generate an `lpop`/`rpop` event (depending on the wherefrom argument) and an `lpush`/`rpush` event (depending on the whereto argument). In both cases the order is guaranteed (the `lpush`/`rpush` event will always be delivered after the `lpop`/`rpop` event). Additionally a `del` event will be generated if the resulting list is zero length and the key is removed.
*   [`LPOP`](/docs/latest/commands/lpop/) generates an `lpop` event. Additionally a `del` event is generated if the key is removed because the last element from the list was popped.
*   [`LPUSH`](/docs/latest/commands/lpush/) and [`LPUSHX`](/docs/latest/commands/lpushx/) generates a single `lpush` event, even in the variadic case.
*   [`LREM`](/docs/latest/commands/lrem/) generates an `lrem` event, and additionally a `del` event if the resulting list is empty and the key is removed.
*   [`LSET`](/docs/latest/commands/lset/) generates an `lset` event.
*   [`LTRIM`](/docs/latest/commands/ltrim/) generates an `ltrim` event, and additionally a `del` event if the resulting list is empty and the key is removed.
*   [`MIGRATE`](/docs/latest/commands/migrate/) generates a `del` event if the source key is removed.
*   [`MOVE`](/docs/latest/commands/move/) generates two events, a `move_from` event for the source key, and a `move_to` event for the destination key.
*   [`MSET`](/docs/latest/commands/mset/) generates a separate `set` event for every key.
*   [`PERSIST`](/docs/latest/commands/persist/) generates a `persist` event if the expiry time associated with key has been successfully deleted.
*   [`RENAME`](/docs/latest/commands/rename/) generates two events, a `rename_from` event for the source key, and a `rename_to` event for the destination key.
*   [`RESTORE`](/docs/latest/commands/restore/) generates a `restore` event for the key.
*   [`RPOPLPUSH`](/docs/latest/commands/rpoplpush/) and [`BRPOPLPUSH`](/docs/latest/commands/brpoplpush/) generate an `rpop` event and an `lpush` event. In both cases the order is guaranteed (the `lpush` event will always be delivered after the `rpop` event). Additionally a `del` event will be generated if the resulting list is zero length and the key is removed.
*   [`RPOP`](/docs/latest/commands/rpop/) generates an `rpop` event. Additionally a `del` event is generated if the key is removed because the last element from the list was popped.
*   [`RPUSH`](/docs/latest/commands/rpush/) and [`RPUSHX`](/docs/latest/commands/rpushx/) generates a single `rpush` event, even in the variadic case.
*   [`SADD`](/docs/latest/commands/sadd/) generates a single `sadd` event, even in the variadic case.
*   [`SETRANGE`](/docs/latest/commands/setrange/) generates a `setrange` event.
*   [`SET`](/docs/latest/commands/set/) and all its variants ([`SETEX`](/docs/latest/commands/setex/), [`SETNX`](/docs/latest/commands/setnx/),[`GETSET`](/docs/latest/commands/getset/)) generate `set` events. However [`SETEX`](/docs/latest/commands/setex/) will also generate an `expire` events.
*   [`SINTERSTORE`](/docs/latest/commands/sinterstore/), [`SUNIONSTORE`](/docs/latest/commands/sunionstore/), [`SDIFFSTORE`](/docs/latest/commands/sdiffstore/) generate `sinterstore`, `sunionstore`, `sdiffstore` events respectively. In the special case the resulting set is empty, and the key where the result is stored already exists, a `del` event is generated since the key is removed.
*   [`SMOVE`](/docs/latest/commands/smove/) generates an `srem` event for the source key, and an `sadd` event for the destination key.
*   [`SORT`](/docs/latest/commands/sort/) generates a `sortstore` event when `STORE` is used to set a new key. If the resulting list is empty, and the `STORE` option is used, and there was already an existing key with that name, the result is that the key is deleted, so a `del` event is generated in this condition.
*   [`SPOP`](/docs/latest/commands/spop/) generates an `spop` event, and an additional `del` event if the resulting set is empty and the key is removed.
*   [`SREM`](/docs/latest/commands/srem/) generates a single `srem` event, and an additional `del` event if the resulting set is empty and the key is removed.
*   [`XADD`](/docs/latest/commands/xadd/) generates an `xadd` event, possibly followed an `xtrim` event when used with the `MAXLEN` subcommand.
*   [`XDEL`](/docs/latest/commands/xdel/) generates a single `xdel` event even when multiple entries are deleted.
*   [`XGROUP CREATECONSUMER`](/docs/latest/commands/xgroup-createconsumer/) generates an `xgroup-createconsumer` event.
*   [`XGROUP CREATE`](/docs/latest/commands/xgroup-create/) generates an `xgroup-create` event.
*   [`XGROUP DELCONSUMER`](/docs/latest/commands/xgroup-delconsumer/) generates an `xgroup-delconsumer` event.
*   [`XGROUP DESTROY`](/docs/latest/commands/xgroup-destroy/) generates an `xgroup-destroy` event.
*   [`XGROUP SETID`](/docs/latest/commands/xgroup-setid/) generates an `xgroup-setid` event.
*   [`XSETID`](/docs/latest/commands/xsetid/) generates an `xsetid` event.
*   [`XTRIM`](/docs/latest/commands/xtrim/) generates an `xtrim` event.
*   [`ZADD`](/docs/latest/commands/zadd/) generates a single `zadd` event even when multiple elements are added.
*   [`ZDIFFSTORE`](/docs/latest/commands/zdiffstore/), [`ZINTERSTORE`](/docs/latest/commands/zinterstore/) and [`ZUNIONSTORE`](/docs/latest/commands/zunionstore/) respectively generate `zdiffstore`, `zinterstore` and `zunionstore` events. In the special case the resulting sorted set is empty, and the key where the result is stored already exists, a `del` event is generated since the key is removed.
*   [`ZINCRBY`](/docs/latest/commands/zincrby/) generates a `zincr` event.
*   [`ZREMRANGEBYRANK`](/docs/latest/commands/zremrangebyrank/) generates a single `zrembyrank` event. When the resulting sorted set is empty and the key is generated, an additional `del` event is generated.
*   [`ZREMRANGEBYSCORE`](/docs/latest/commands/zremrangebyscore/) generates a single `zrembyscore` event. When the resulting sorted set is empty and the key is generated, an additional `del` event is generated.
*   [`ZREM`](/docs/latest/commands/zrem/) generates a single `zrem` event even when multiple elements are deleted. When the resulting sorted set is empty and the key is generated, an additional `del` event is generated.
*   Every time a key with a time to live associated is removed from the data set because it expired, an `expired` event is generated.
*   Every time a key is evicted from the data set in order to free memory as a result of the `maxmemory` policy, an `evicted` event is generated.
*   Every time a new key is added to the data set, a `new` event is generated.
*   Every time a key is being overwritten, an `overwritten` event is generated.
*   Every time a key's type changes, a `type_changed` event is generated.

**IMPORTANT** all the commands generate events only if the target key is really modified. For instance an [`SREM`](/docs/latest/commands/srem/) deleting a non-existing element from a Set will not actually change the value of the key, so no event will be generated.

If in doubt about how events are generated for a given command, the simplest thing to do is to watch yourself:

```
$ redis-cli config set notify-keyspace-events KEA
$ redis-cli --csv psubscribe '__key*__:*'
Reading messages... (press Ctrl-C to quit)
"psubscribe","__key*__:*",1
```

At this point use `redis-cli` in another terminal to send commands to the Redis server and watch the events generated:

```
"pmessage","__key*__:*","__keyspace@0__:foo","set"
"pmessage","__key*__:*","__keyevent@0__:set","foo"
...
```

### Timing of expired events

Keys with a time to live associated are expired by Redis in two ways:

*   When the key is accessed by a command and is found to be expired.
*   Via a background system that looks for expired keys in the background, incrementally, in order to be able to also collect keys that are never accessed.

The `expired` events are generated when a key is accessed and is found to be expired by one of the above systems, as a result there are no guarantees that the Redis server will be able to generate the `expired` event at the time the key time to live reaches the value of zero.

If no command targets the key constantly, and there are many keys with a TTL associated, there can be a significant delay between the time the key time to live drops to zero, and the time the `expired` event is generated.

Expired (`expired`) events are generated when the Redis server deletes the key and not when the time to live theoretically reaches the value of zero.

### Events in a cluster

Every node of a Redis cluster generates events about its own subset of the keyspace as described above. However, unlike regular Pub/Sub communication in a cluster, events' notifications **are not** broadcasted to all nodes. Put differently, keyspace events are node-specific. This means that to receive all keyspace events of a cluster, clients need to subscribe to each of the nodes.

@history

*   `>= 6.0`: Key miss events were added.
*   `>= 7.0`: Event type `new` added

## On this page
