🚨 Redis Error Guide: 'ERR invalid expire time in set command' — Fix Bad TTL Values

Overview

Redis returns invalid expire time when a command is given a TTL that is not a positive integer within range. It appears on SET ... EX/PX, SETEX, PSETEX, EXPIRE, and GETEX. The rule is simple: expiry values must be integers greater than zero (for the relative-TTL commands), and small enough not to overflow Redis’s internal millisecond timestamp.

The literal error clients receive:

(error) ERR invalid expire time in 'set' command

The command name varies ('setex', 'expire', 'getex'). The usual causes are a computed TTL that came out 0 or negative, a float where an integer is required, or a seconds value mistakenly passed to a milliseconds parameter (or vice versa) so it overflows.

Symptoms

• Writes fail only when a TTL is supplied; the same SET without expiry works.
• The failing TTL was computed at runtime (e.g. expiry - now) and drifted to 0 or negative.
• Appears after switching between EX (seconds) and PX (milliseconds).

redis-cli SETEX session:1 0 payload

(error) ERR invalid expire time in 'setex' command

Common Root Causes

1. Zero or negative TTL

SETEX/PSETEX and SET ... EX/PX require a value strictly greater than zero.

redis-cli SET k v EX 0      # zero
redis-cli SET k v EX -5     # negative

Both fail. (Note: EXPIRE with a non-positive time is valid — it deletes the key immediately — but SET ... EX 0 is rejected.)

2. A float TTL where an integer is expected

redis-cli SET k v EX 1.5

(error) ERR value is not an integer or out of range

Fractional seconds must use PX in whole milliseconds.

3. Seconds/milliseconds unit mixup causing overflow

Passing a milliseconds value to EX (seconds) can exceed the maximum expiry Redis will accept.

redis-cli SET k v EX 99999999999999

(error) ERR invalid expire time in 'set' command

4. Computed TTL drifted below zero

ttl = deadline - now() returns a negative number once the deadline has passed.

How to diagnose

Step 1: Print the TTL your code computed

Log the exact value passed as the expiry before the call. A 0, negative, or float value is the smoking gun.

Step 2: Reproduce with the literal value

redis-cli SET k v EX 3600     # a known-good TTL
redis-cli SET k v EX 0        # the failing value

Step 3: Confirm which unit the command expects

redis-cli SETEX k 60 v        # 60 SECONDS
redis-cli PSETEX k 60000 v    # 60000 MILLISECONDS

Step 4: Check for overflow on absolute-time flags

EXPIREAT/PEXPIREAT take Unix timestamps; a milliseconds timestamp sent to EXPIREAT (seconds) is far in the future and can be rejected.

redis-cli EXPIREAT k 1752307200      # seconds since epoch
redis-cli PEXPIREAT k 1752307200000  # milliseconds since epoch

Fixes

Guard the TTL to be a positive integer

ttl = max(1, int(deadline - now))   # never 0 or negative, always int
r.set("session:1", payload, ex=ttl)

Use PX for sub-second expiry

redis-cli SET k v PX 1500      # 1.5 seconds, expressed in ms

Match value to unit deliberately

redis-cli SETEX session:1 60 payload      # 60 seconds

To delete instead of expire, be explicit

If a non-positive TTL is a legitimate “delete now” signal, call DEL rather than relying on expiry semantics.

redis-cli DEL session:1

What to watch out for

• EXPIRE key 0 (or negative) is accepted and deletes the key immediately, but SET key val EX 0 is rejected. The semantics differ by command.
• Redis rejects expiry times that would overflow its internal signed millisecond timestamp; keep absolute times realistic.
• A fractional TTL usually surfaces as value is not an integer or out of range rather than invalid expire time — check both when a computed TTL fails.
• Client libraries that accept a timedelta will convert to whole seconds; verify rounding does not produce 0.

Related

• Redis Error: ‘ERR syntax error’
• Redis Error: ‘value is not an integer or out of range’
• Redis Error: ‘ERR wrong number of arguments for command’

Paste the failing command into the free incident assistant, and browse more Redis guides.