Skip to main content
Use XPENDING to inspect the entries that a consumer group has delivered but not yet acknowledged. With only a key and a group, the reply is a summary: how many entries are pending, the lowest and highest pending IDs, and the number of pending entries per consumer. That is the cheap form to poll for monitoring. The extended form, with a start, an end, and a count, lists the pending entries one by one with the consumer that owns each, how long it has been idle, and how many times it has been delivered. IDLE restricts the listing to entries idle for at least the given number of milliseconds, and a consumer name restricts it to one worker. A high delivery count points at an entry that keeps failing, and a long idle time points at a consumer that died holding work. Both are handed over to another consumer with XCLAIM or XAUTOCLAIM.

Syntax

Arguments

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.
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.