Use XINFO GROUPS to list the consumer groups defined on a stream.
Each group is reported with its name, its number of consumers, how many entries are pending across the group, the ID it has delivered up to, and its lag, meaning how many entries in the stream it has not read yet. Lag and pending count together are the standard health signals for a stream consumer: a growing lag means consumers cannot keep up, while a growing pending count means they read entries but do not acknowledge them.
Syntax#
Arguments#
| Argument | Required | Repeatable | Description |
|---|---|---|---|
<key> | Yes | No | Redis key targeted by the command. |
Response#
The reply reports the result of the operation. Error replies have the same shape in RESP2 and RESP3 and are surfaced as exceptions by the SDKs below.
| Protocol | Reply |
|---|---|
| RESP2 | Array of flat group-metadata arrays |
| RESP3 | Array of group-metadata maps |
Client libraries often decode bulk strings, maps, sets, and numeric strings into language-native values. The table describes the Redis wire reply.
Examples#
TCP examples use the TLS REDIS_URL from the Upstash console. REST examples use UPSTASH_REDIS_REST_URL and UPSTASH_REDIS_REST_TOKEN.