Replaying Missed Events

How events slip through

Even with retries working as designed, events can still be missed. If your endpoint is down for longer than the provider's retry window, those deliveries are eventually abandoned and never come back of their own accord. A misconfiguration, an expired TLS certificate, or a deploy gone wrong can each open a window in which deliveries fail and are then quietly given up on, with no alarm raised.

Relying solely on the live stream therefore always leaves a potential gap. The cure is to have a deliberate recovery path planned in advance: a reliable way to learn what you missed and bring your state back into line once the endpoint is healthy again. Designing this before an incident strikes is enormously better than improvising it under pressure while data diverges and stakeholders ask why.

Reconcile against the truth

The most robust form of recovery is reconciliation: periodically compare your local state with the provider's authoritative state through the API, and correct any differences you find. This approach does not depend on individual events at all — it simply asks what is true right now? and updates your records to match, regardless of how it got out of step.

A nightly or hourly reconciliation job means that even a long webhook outage self-heals on the very next run, with no manual intervention. It is the surest backstop precisely because it sidesteps the entire question of which deliveries did or did not arrive. For the broader comparison of push against pull, see webhooks vs polling, which frames reconciliation as the polling half of a hybrid design.

Replay where it is offered

Some providers let you replay past events — re-sending deliveries from a chosen point in time, or exposing a log of recent events that you can fetch and reprocess on demand. Where this facility exists, it is a precise recovery tool: you catch up on exactly the events you missed during the outage, without having to run a full reconciliation across everything.

Replay leans heavily on idempotency, because replayed events will inevitably overlap with ones you already handled before the outage. With idempotent processing in place, reprocessing that overlap is completely harmless and produces no double effects. Check the API documentation to see precisely what replay windows or event-log facilities a provider offers before you depend on them.

Defence in depth

The strongest posture combines several approaches rather than betting everything on one. Use webhooks for prompt notification in the common case, make your processing idempotent so that repeats are always safe, and run a scheduled reconciliation as the ultimate safety net beneath both. Each layer covers a weakness of the others: webhooks give you speed, reconciliation gives you completeness, idempotency makes their overlap painless.

Build the recovery path early, while the system is calm and you can think clearly, and then test it on purpose rather than discovering its flaws during a real incident. An untested recovery plan has a habit of failing at exactly the moment you most need it to work. Done well, a missed-event scenario becomes a routine, almost boring, catch-up.