Replay and retention.
Two kinds of replay — one for messages that failed, one for messages that succeeded — and one retention window per plan.
Replay undelivered messages
If a destination is down for long enough, its messages are parked as undelivered. When it is back, open the destination's recovery panel in the console and replay one message or all of them (or call POST /api/sinks/{id}/replay).
Replayed messages go back to pending with a fresh budget of five attempts — you replaying is a good sign the destination is healthy again. Order is kept automatically: a replayed message has the lowest sequence number for its row, so the messages waiting behind it follow in order. The earlier attempts stay visible in the message's history.
Re-deliver messages that were already delivered
Sometimes you want messages again even though they were delivered — a consumer bug ate them, or a new destination wants recent history. Call POST /api/sinks/{id}/replay-delivered with {"from","to"} timestamps in RFC 3339, and every message captured in that range is delivered again.
The range has to fall inside your plan's replay window; a range beyond it is refused. Replay can only draw on what Waltail still holds, which is everything captured within retention.
Retention
| Plan | Retention and replay window |
|---|---|
| Free | 24 hours |
| Pro | 7 days |
| Scale | 30 days |
| Enterprise | Custom |
Stored changes and the delivery log are kept in daily partitions and dropped when they age out. Inside the window, the message explorer in the console shows every captured message with its state per destination, and lets you filter by table, state and time.
Giving a new destination the past
A destination added to a running pipeline receives changes from the moment you add it. For recent history, use replay-delivered. For the rows that exist now, run a backfill.