Redis AOF persistence logs every write operation, but the appendfsync policy controls when Redis asks the operating system to flush that log to durable storage. That choice determines the trade-off between write latency and the amount of recent data that may be lost after a failure.

appendfsync always makes each acknowledged batch wait for fsync, so slow storage directly increases client latency. appendfsync no leaves flushing to the operating system, so the potential loss window depends on kernel and storage behavior.

The policy is the boundary between durability and latency. This article covers the mechanics of the three fsync modes, their production failure modes, and the signals that reveal disk I/O saturation.

What it is and why it matters

The Append Only File (AOF) reconstructs the dataset on startup by replaying write operations. Redis appends new operations to the AOF and applies one of three flush policies. With always, Redis performs the fsync before replying. With everysec, the flush normally runs once per second in a background thread. With no, Redis writes to the file but does not explicitly request an fsync.

How it works

Redis supports three fsync policies.

PolicyAcknowledgement and flushing behaviorOperational trade-off
alwaysRedis appends a batch of commands, calls fsync, and replies after the flush completesStrongest durability policy and highest sensitivity to storage latency
everysecRedis requests an fsync about once per second using a background threadDefault and recommended balance; a failure may lose about one second of writes
noRedis does not call fsync; the operating system decides when to flushLowest explicit flush overhead and the least predictable loss window

Redis can group commands received from multiple clients or a pipeline into one write and one fsync, but always still puts durable-storage latency on the acknowledgement path. A slow fsync therefore appears directly in client response time.

With everysec, Redis normally keeps the fsync off the main thread. If a background flush remains in progress, Redis can delay another AOF write for up to two seconds before attempting the write anyway. This can still create latency when the storage device is saturated.

flowchart TD
    A[Client write batch] --> B[Append commands to AOF]
    B --> C{appendfsync policy}
    C -->|always| D[fsync before reply]
    C -->|everysec| E[background fsync about once per second]
    C -->|no| F[operating system schedules flush]
    D --> G[Client latency follows fsync latency]
    E --> H[About one second of writes may be lost]
    F --> I[Loss window depends on OS and storage]

Common causes

CauseWhat it looks likeFirst thing to check
appendfsync always on high-latency storageWrite latency tracks disk flush latency; aof-fsync-always events appearCONFIG GET appendfsync and LATENCY HISTORY aof-fsync-always
Competing disk I/OLatency worsens during backups, snapshots, or AOF/RDB background workDevice latency and utilization with iostat -x 1
Slow or throttled network-attached volumePeriodic or sustained fsync stalls despite moderate Redis CPUCloud-volume latency, queue, and burst-credit metrics
AOF rewrite overlapLatency correlates with aof_rewrite_in_progress or fork activityINFO persistence and LATENCY LATEST
Policy does not match the durability requirementalways is used where one-second loss is acceptable, or no is used for critical dataApplication recovery-point objective and current configuration

Quick checks

# Confirm that AOF is enabled and identify the fsync policy
redis-cli CONFIG GET appendonly
redis-cli CONFIG GET appendfsync
redis-cli CONFIG GET no-appendfsync-on-rewrite

# Inspect AOF health and background activity
redis-cli INFO persistence | grep -E \
  "aof_enabled|aof_rewrite_in_progress|aof_last_bgrewrite_status|aof_last_write_status|aof_pending_bio_fsync|aof_delayed_fsync"

# Inspect Redis latency events. The monitor must already be enabled.
redis-cli LATENCY LATEST
redis-cli LATENCY HISTORY aof-fsync-always
redis-cli LATENCY HISTORY aof-write-pending-fsync

# Check storage latency on the Redis host
iostat -x 1

Redis latency monitoring is disabled when latency-monitor-threshold is 0. Set its threshold according to the application’s latency requirement; do not copy a universal threshold from another workload.

How to diagnose it

  1. Confirm the active policy. Run CONFIG GET appendfsync. Do not infer it from a template or an old configuration file because runtime configuration may differ.
  2. Measure client-visible latency. Compare write latency with read-only commands. If only writes slow down, persistence is a stronger suspect than command complexity or network latency.
  3. Inspect Redis latency events. The aof-fsync-always event records slow fsync calls under the always policy. aof-write and aof-write-pending-fsync show AOF write stalls, including stalls while another flush is pending.
  4. Check AOF state. In INFO persistence, confirm that the last AOF write and rewrite succeeded. A rising aof_delayed_fsync counter or pending background flush jobs indicates that storage is not keeping up.
  5. Correlate with the storage device. Use device latency, queue depth, and utilization—not Redis CPU alone. AOF latency can be storage-bound while the Redis process uses little CPU.
  6. Look for competing I/O. Check whether the latency begins during an AOF rewrite, RDB snapshot, host backup, log rotation, or another process writing to the same device.
  7. Confirm the durability requirement. Decide how much acknowledged data the application may lose after a host or operating-system failure. That requirement determines whether changing the policy is acceptable.

Metrics and signals to monitor

SignalWhy it mattersWarning sign
Application write latencyDirect user impact of synchronous persistenceDeviation from the workload’s established latency objective
aof-fsync-always latency eventsMeasures slow flushes under appendfsync alwaysNew or recurring events above the configured latency threshold
aof-write-pending-fsync eventsShows writes delayed while a background flush is activeRecurring events correlated with client latency
aof_delayed_fsyncCounts delayed AOF flushesCounter increasing during normal traffic
aof_pending_bio_fsyncBackground flush work waiting to completeRemaining above zero instead of clearing
aof_last_write_statusReports whether the latest AOF write succeedederr
aof_last_bgrewrite_statusReports whether the latest AOF rewrite succeedederr
Device latency and queue depthConfirms storage as the bottleneckSustained increase correlated with Redis writes

Fixes

Keep appendfsync always

If the application requires the strongest Redis AOF durability policy, keep always and fix the storage path. Remove unrelated I/O from the device, verify that the filesystem and volume honor flush requests promptly, and use storage with stable low fsync latency. Reduce the write rate temporarily if the device cannot keep up.

Benchmark the real persistence volume with the application write pattern. A storage throughput benchmark alone is insufficient because always is dominated by flush latency, not sequential bandwidth.

Change to appendfsync everysec

Redis documents everysec as the default and recommended compromise. It normally keeps fsync work in a background thread and may lose about one second of writes after a failure.

Changing to everysec is a durability decision, not a performance tweak. Make the change only when the application’s recovery-point objective explicitly accepts that loss window, and persist the approved setting in the managed Redis configuration.

Keep appendfsync no

With no, Redis does not request an fsync; the operating system controls flushing. Use it only when the application can reconstruct or discard recent data and accepts a loss window determined by the host’s kernel and storage configuration.

Remove competing I/O

Move backups, log-heavy workloads, and other persistence jobs away from the Redis volume. Schedule AOF rewrites and snapshots so they do not overlap with known write peaks. Recheck Redis latency events and device metrics after each change.

Prevention

  • Record the required recovery-point objective before selecting an AOF policy.
  • Monitor client write latency together with Redis AOF events and storage latency.
  • Enable Redis latency monitoring with a threshold derived from the application’s own latency objective.
  • Alert when aof_delayed_fsync increases or the last AOF write/rewrite status changes to err.
  • Test persistence behavior on the same storage class used in production, including during rewrites and backups.
  • Review runtime configuration after deployments so appendfsync does not drift from the approved policy.

How Netdata helps

  • Correlate Redis PING latency and command throughput with disk latency, queue depth, and utilization on the AOF volume.
  • Compare current and base AOF size with rewrite activity and host backup windows to identify persistence-related pressure.
  • Use the native Redis INFO persistence and LATENCY checks above for fields and events that the current Redis collector does not chart.
  • Alert on deviations from the workload’s established latency objective instead of applying a universal latency threshold.