Mar 23, 2026

Last updated on Mar 31, 2026

Redis Eviction Policy Guide: Why Keys Disappear

When Redis keys seem to disappear randomly, the cause is often not corruption. It is usually eviction doing exactly what the configured memory policy told Redis to do. The confusion comes from the fact that missing keys, expired keys, overwritten keys, and rejected writes can all look similar from the application side.

The short version: confirm whether Redis is actually under maxmemory pressure, confirm which eviction policy is active, and only then decide whether disappearing keys are caused by eviction, expiration, or application behavior.

What eviction means in Redis

Redis applies eviction only when memory pressure interacts with a configured maxmemory limit.

That means disappearing keys under pressure are often expected behavior, not mysterious behavior. Your first checks should be:

is maxmemory configured?
what is maxmemory-policy?
are you actually under pressure right now?

If the answer to the last question is no, missing keys are more likely explained by expiration, overwrite, deletion, or application logic.

Why keys disappear differently under different policies

Redis supports policies such as:

noeviction
allkeys-lru
allkeys-lfu
allkeys-random
volatile-lru
volatile-lfu
volatile-random
volatile-ttl

The critical difference is whether Redis can evict from all keys or only from keys that already have TTL.

If a team assumes “only cache keys should disappear” but the policy is allkeys-*, Redis may be behaving correctly while the incident still feels surprising.

Eviction, expiration, and overwrite are not the same thing

Teams often group these together, but the debugging path changes depending on which one is really happening.

eviction: Redis removes keys because of memory pressure plus policy
expiration: keys disappear because TTL reached zero
overwrite or delete: the application changed or removed the key

If keys are not expiring when they should, the next guide is Redis Keys Not Expiring.

If writes are failing instead of keys disappearing, compare the same incident with Redis OOM Command Not Allowed.

Check whether the real problem is missing TTL

Eviction issues and TTL issues often appear together.

A common pattern looks like this:

the app expects cache keys to expire
some keys lose TTL after overwrite
memory rises
eviction begins affecting keys in a way the team did not expect

In that case, policy is only part of the story. TTL behavior is the earlier branch.

Common policy misunderstandings

1. Assuming `volatile-*` affects all keys

It does not. Those policies consider only keys with TTL.

2. Assuming `noeviction` means nothing bad happens

It means Redis avoids eviction and can fail writes that need additional memory instead.

3. Assuming eviction explains every missing key

Sometimes the application overwrote, deleted, or expired the key instead.

4. Forgetting that workload shape changes the outcome

The same policy can feel very different under bursty writes, large values, or bad TTL hygiene.

A practical debugging order

inspect current memory usage
inspect maxmemory
inspect maxmemory-policy
confirm whether the missing keys had TTL
inspect whether writes are also failing
decide whether the current policy matches the data importance model

This sequence is usually safer than changing policy immediately during an incident.

Quick commands to ground the investigation

redis-cli CONFIG GET maxmemory
redis-cli CONFIG GET maxmemory-policy
redis-cli INFO memory
redis-cli INFO stats

Use these commands to confirm whether Redis is allowed to evict keys, whether pressure is real, and whether evicted-key counters are rising during the incident.

A simple decision shortcut

Use this fast branch when keys seem to disappear:

memory pressure is high and evicted_keys rises: think eviction first
TTL is counting down as expected: think expiration first
memory pressure is low and TTL is missing: think overwrite or delete first
writes fail with OOM errors: think noeviction or exhausted memory first

That shortcut will not replace a full incident review, but it often prevents teams from blaming the wrong subsystem for the first 30 minutes.

Symptom shortcuts

Start here if keys disappear unexpectedly under memory pressure.
If keys are not expiring at all, the TTL guide is usually the better first stop.
If writes are failing with OOM errors, the OOM guide is usually the more direct entry.

FAQ

Q. Why are only some keys disappearing?

Because the active policy may target only volatile keys or may prefer certain access patterns such as LRU or LFU.

Q. Does `noeviction` protect writes?

No. It avoids eviction and can cause writes that need more memory to fail instead.

Q. What should I inspect first?

Check maxmemory, maxmemory-policy, and whether the missing keys had TTL.

Q. When is policy not the main problem?

When memory pressure is weak or absent, or when the real issue is expiration or application overwrite behavior.

Start Here

Continue with the core guides that pull steady search traffic.