Use EXPIREAT to schedule a key for automatic deletion at a fixed point in time, given as a Unix timestamp in seconds.
It behaves exactly like EXPIRE except that the deadline is absolute rather than relative, which is what you want when several keys must expire at the same moment, such as the end of an hour or of a billing period. Computing the deadline once and reusing it also avoids the drift that repeated relative expirations introduce. A timestamp in the past deletes the key right away.
The optional condition works as it does for EXPIRE: NX only when the key has no expiration, XX only when it already has one, GT only when the new deadline is later than the current one, and LT only when it is earlier.
Syntax#
Arguments#
| Argument | Required | Repeatable | Description |
|---|---|---|---|
<key> | Yes | No | Redis key targeted by the command. |
<unix-time-seconds> | Yes | No | Expiration time as a Unix timestamp in seconds. |
(NX | XX | GT | LT) | No | No | Choose one form: NX (only when the key has no expiration); XX (only when the key already has one); GT (only when the new expiration is later than the current one); LT (only when it is earlier). |
Important points#
NXcannot be combined withXX,GT, orLT, andGTandLTcannot be used together.- A key with no expiration counts as an infinite one, so
GTnever sets an expiration on such a key andLTalways does.
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 | Integer: 1 if the timeout was set, 0 otherwise |
| RESP3 | Integer: 1 if the timeout was set, 0 otherwise |
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.