Skip to main content
Use XREAD to read entries from one or more streams that are newer than a given ID. After STREAMS, all keys are listed first and then exactly one ID for each key, in the same order. Only entries with an ID greater than the one you give are returned, and the special ID $ means “only entries added after this call”, which is how a client starts tailing a live stream. BLOCK <milliseconds> waits for new data instead of returning an empty reply, with 0 waiting indefinitely, which turns the command into an efficient follow rather than a polling loop. COUNT caps how many entries per stream come back. XREAD keeps no server-side position: the client remembers the last ID it processed and passes it on the next call, and every reader sees every entry. When work should be split across consumers, with the server tracking what has been delivered and acknowledged, use a consumer group and XREADGROUP.

Syntax

Arguments

Important points

  • A blocking form holds the request until data arrives or its timeout expires. Set the client/network timeout longer than the command timeout.
  • After STREAMS, provide all keys first and then exactly one ID for each key, in the same order.

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.