## TL;DR

Redis hit its memory cap and, with a noeviction policy, now refuses all writes to protect your data. The safe response is to free memory deliberately: check what is actually using it - big keys, expired-but-not-evicted data - delete or expire what you can, and only then decide whether to raise maxmemory or change the eviction policy. Do not just raise the cap without understanding what filled it, or it will fill again.

```text
Redis "OOM command not allowed when used memory > maxmemory": how to respond
```

## Steps

1. Confirm the memory picture: used memory versus maxmemory, and the current eviction policy.
Expected: You know how far over the cap it is and that the policy is noeviction.

2. Find the biggest memory consumers: sample large keys and check per-namespace key counts and TTLs.
Expected: You know which keys or namespaces dominate memory.

3. Delete or set TTLs on data you can reclaim: stale cache entries, orphaned keys, oversized values.
Expected: Used memory drops back under maxmemory.

4. Choose the durable fix: raise maxmemory if the host has RAM to spare, switch to an eviction policy that fits the workload, or add capacity.
Expected: Writes succeed and memory stays under the cap under normal load.

## Use this when

- Write commands fail with OOM command not allowed.

- Memory usage is at or above the configured maxmemory.

- A deploy or traffic spike suddenly grew key volume.

## Not for this skill when

- Redis down or unreachable (process or network problem).

- Replication lag or persistence failures.

- Read errors or wrong-type errors on keys.

## Variant phrasings

### redis OOM command not allowed

### redis maxmemory exceeded

### redis out of memory noeviction

## Why it happens

maxmemory caps how much RAM Redis will use. With the noeviction policy, hitting the cap means Redis rejects writes rather than silently deleting your data. Something filled memory - a hot key pattern, missing TTLs, or genuine growth - and the cap did its job.

## Edge cases

- Eviction policies trade differently: allkeys-lru evicts anything, volatile-lru only keys with TTLs - pick the one matching your data.

- Replication output buffers and AOF rewrite buffers count toward memory during heavy operations.

- RDB or AOF rewrites temporarily spike memory through copy-on-write - a borderline instance OOMs exactly during saves.

- The built-in memory doctor report summarizes fragmentation and allocator issues worth a look.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_PoBsBpQcn6Fwb1nhKK8rdA