Reading the redundancy map: N of M copies, catching up, and down

The redundancy map is where the console shows how many proven copies a fan-out downpipe actually has, which destinations are unreachable, and which are still catching up. This page is for the operator reading that view, so you can tell a normal post-run lag apart from a real shortfall and trust the numbers as proven outcomes rather than guesses.

Everything on this view is derived from per-destination replication state the engine records from what each destination is proven to hold and whether the last attempt to it succeeded. It is never inferred from staleness, the canary, or any other signal. For the engine machinery underneath it, see failover and replication. For the whole-estate picture this drawer sits inside, see the topology map.

The Copies row, field by field

Open a fan-out downpipe in the map’s drawer and you get a Copies row. It reads as N of M copies, optionally followed by a state. M is the number of destinations this downpipe is configured to fan out to (its intended width), and N is how many of those destinations are proven to hold the latest successful run.

A destination counts toward N only when its proven holdsRunId equals the downpipe’s latest successful run id. Anything less, whether reachable-but-behind, never-reported, or unreachable, does not count, so the figure cannot read greener than the proven truth.

The five redundancy states

The roll-up that backs the Copies row resolves to one of five states. Knowing which state you are in tells you whether to act.

A partial state right after a run is the expected case, not a fault. It resolves on its own once replication catches the remaining destinations up.

Per-destination edges and the down badge

The map draws one edge per destination a downpipe writes to, rather than a single shared edge. Each edge carries its own status, layered over the downpipe’s own capture status, so no single destination’s lane can read greener than the run itself.

For a downpipe whose capture is healthy, each destination lane reads as follows.

If the downpipe’s own capture is failed, disabled, or in an unknown state, every lane shows that capture state unchanged. The data itself is not safe or not measured, so the redundancy overlay never paints a lane greener than the run. A destination added moments ago, before it has a replication record at all, reads as partial rather than no copy: no-copy is reserved for a destination the evidence proves has stayed empty, never for one that simply has not reported yet.

A destination node carries a down badge the moment any downpipe reports it unreachable. Because one destination is often shared by several downpipes, the badge is aggregated across them, so it never under-reports an outage: one downpipe finding the destination unreachable is enough to badge it down for the whole map.

Why catching up right after a run is normal

This is the single most important expectation to set. A copy showing catching up immediately after a run is the normal, healthy case, not a problem.

The reason is structural. A run is first sealed to one destination, and replication to the other destinations runs as a separate scheduled pass, not inline during the seal. The engine ticks roughly every fifteen minutes, so a freshly sealed run reaches the other destinations on a later tick. In the window between the seal and that pass, the other destinations genuinely do not hold the new run yet, and the map says so honestly rather than pretending otherwise.

So a downpipe that just ran will often read 2 of 3 copies - catching up for a tick or two, then settle to 3 of 3 copies once replication completes. A recovered destination is likewise re-probed on the next tick rather than the instant it comes back. Read every catching up here as on a tick, not in real time.

Why the numbers cannot over-claim

The honesty of this view rests on one rule: a destination’s recorded holdsIndex advances only to the highest contiguous run it holds, with no gap below it. The first missing run stops it.

That matters because runs can land on a destination out of global order under failover and backlog catch-up. If a destination holds runs 1, 2, and 4 but is missing run 3, the recorded index stays at run 2, not run 4. Recording a higher index would over-claim a copy the destination lacks, which would both inflate the Copies count and fool the removal orphan-guard that trusts the index to mean holds every run up to here. A run skipped because its origin was unreadable freezes the recorded index below it until the gap fills.

The recorded state also moves forward only by index, so a late or duplicate record can never rewind a destination’s proven copy. And a reachable destination that could mirror nothing this pass refreshes its reachability heartbeat without advancing what it holds, so an outage and a quiet-but-current copy are never confused.

The map reading is not the posture control

It is worth keeping two different things apart. The redundancy map is where proven landing is surfaced: it tells you what destinations actually hold the latest run right now. The redundant-copies posture control is a separate check that looks at the configured destination count, not at proven copies.

So a downpipe can satisfy the posture control by being configured for enough destinations while its map still reads partial because replication has not yet caught every destination up. A full map reading and a passing posture control are related but not the same statement, and you should not read one as proving the other. The map is the proven-landing view; the posture control is the configured-intent view.

Where this fits

Last updated 4 August 2026.