Applying a change in the control plane is not the same as serving it. Each edge node that serves a zone polls for new configuration, applies it and reports what it applied. Propagation compares the two sides:
- Desired version: the zone's current version, the one every node should serve.
- Applied version: for each node, the zone version in the last configuration that node confirmed.
Timing
A node applies a change within one polling interval, about 30 seconds. The control plane only learns that it did on the node's next poll, so the confirmation arrives after about two intervals, roughly 60 seconds. A node that shows as pending for a minute right after a change is normal.
Node statuses
| Status | Meaning |
|---|---|
converged | The node applied the desired version (or a later one). |
pending | It has not applied it yet, for less than 60 seconds. |
lagging | 60 seconds or more without converging. If it persists, the node may be rejecting its configuration; OpenWAF's monitoring has the reason. |
offline | The node has not polled for more than 3 minutes, or never has. |
revoked | The node was removed from the fleet and serves nothing. |
retiring | The node no longer has to serve the zone, but the configuration it applied still includes it. It disappears from the list once it applies one without the zone. |
Each node also reports applied_version, pending_since (when the first version it has not applied was created), lag_seconds (how long it has been pending or, once converged, how long it took) and last_seen_at.
Wait for propagation
The CLI can wait for a change to reach every node: add --wait (120 seconds by default) or --wait=90s to any zone change. It prints each node as it confirms and ends with exit code 4 if some node has not converged in time. If the zone changes again while it waits for a node to retire, it stops with exit code 3.
openwaf-cloud ctl records set example.com www/A content=203.0.113.20 --reason "Move www" --yes --waitStep-by-step, from every interface: Check propagation.