Last AOF Rewrite Status, Redis

​

At a glance

Last AOF Rewrite Status reports whether the most recent Append-Only File rewrite finished cleanly. It reads aof_last_bgrewrite_status from INFO persistence, which is either ok or err. The AOF is Redis’s write-ahead log; it is periodically rewritten (compacted) so it does not grow without bound. If a rewrite fails, the AOF stops shrinking and can keep growing on disk, and your durability guarantee quietly weakens. This is a binary health flag, not a trend: ok is fine, err means the last compaction failed and someone needs to find out why before the next restart depends on a broken file.

​

Calculation

status = INFO persistence -> aof_last_bgrewrite_status

ok   -> green   (last rewrite completed cleanly)
err  -> red     (last rewrite failed; ALERT)
n/a  -> grey    (aof_enabled:0; AOF is off, card not applicable)

# Persistence
aof_enabled:1
aof_rewrite_in_progress:0
aof_last_bgrewrite_status:ok      <- this card
aof_last_write_status:ok          <- different: per-write fsync health
aof_rewrite_scheduled:0
aof_last_cow_size:8388608
aof_current_size:734003200
aof_base_size:367001600

​

Worked example

aof_enabled:1
aof_last_bgrewrite_status:ok
aof_current_size:1.4 GB
aof_base_size:0.7 GB        (file has doubled -> auto-rewrite due soon)
disk free on AOF volume: 6.1 GB

Diagnosis: the AOF volume ran low on space. The rewrite child needs room
to write a fresh compacted file alongside the old one before swapping;
with only 0.4 GB free and a 4.8 GB AOF, the rewrite could not complete
and Redis set aof_last_bgrewrite_status:err. The file is now uncompacted
and growing, which makes the disk-full problem worse on every write.

Risk: if the node restarts now, AOF load is slow (4.8 GB to replay) and,
if a write hit a full disk, aof_last_write_status may also be err, meaning
recent writes were not durably persisted.

1. A failed rewrite is rarely about Redis; it is usually disk or fork headroom. The two dominant causes are a full volume and a failed fork() under memory pressure (no overcommit headroom). Check those first, not Redis config.
2. An err status is also a self-worsening problem. A failed rewrite means the file keeps growing, which makes the next rewrite need even more disk and even more likely to fail. It does not self-heal; you must intervene.
3. Rewrite status and write status are different durability signals. aof_last_bgrewrite_status:err means compaction failed (operational nuisance, slow restart). aof_last_write_status:err means recent writes did not reach disk (data loss risk). They share a root cause here (full disk) but mean different things; always check both.

​

Sibling cards

​

Reconciling against the source

INFO persistence for the field itself plus its context: redis-cli INFO persistence | grep -E 'aof_'. Read aof_last_bgrewrite_status, aof_last_write_status, aof_current_size, aof_base_size, and aof_rewrite_in_progress together. BGREWRITEAOF to trigger a manual rewrite; watch the Redis log (logfile or stdout) for the child-process success or failure line. The Redis server log itself, which records the precise reason for a failed rewrite (for example “Can’t rewrite append only file in background: fork: Cannot allocate memory” or a disk-write error). CONFIG GET appendonly to confirm AOF is actually enabled; if no, this card is not applicable. CONFIG GET dir and a disk check (df -h) on that directory to confirm there is room for a rewrite.

​

Known limitations / FAQs

​

Tracked live in Vortex IQ Nerve Centre