LV2 · Toolooo Standard
Webhook Delivery Simulator
See how failures, retries, and duplicate events affect webhook delivery and processing.
Delivered once ≠ processed once
Watch one event become several attempts, then see which attempts repeat a business action.
After a failed response or timeout, wait 1.00s → 2.00s → 4.00s. The event-age limit can stop the sequence earlier.
9 extra effects in this run. Delivery attempts and acknowledgement timing stay the same in this comparison.
Timeouts, duplicate copies, retry age & recovery
Snapshot at 45s
Original events = acknowledged + exhausted + pending. Attempts = timely 2xx + failed responses + timeouts + in flight. Traffic continues through the chosen duration, so recent events may still be pending.
Same deliveries, different side effects
First effect + repeated effect. Both rows use exactly the same seeded attempt outcomes. Suppression assumes an atomic check and commit; it does not model faster duplicate responses.
Events awaiting provider acknowledgement
The line includes in-flight attempts and waits for retries. It falls when an event is acknowledged or its policy is exhausted. This is a delivery backlog, not a receiver-capacity queue.
Inspect event #1
● Provider decision · ◆ Receiver completion · dashed segment = processing continues after timeout. Times on the chart are relative to this event’s creation.
Model assumptions & limits
- Fixed seeded draws make each scenario repeatable. Failure probability is applied independently to each attempt until recovery; after recovery it is 0%. This is a sample, not a specific provider forecast.
- Events arrive evenly; the receiver has unlimited concurrency. Every attempt takes the selected handler latency and either fails before an effect or completes successfully.
- A successful completion returns 2xx. If it arrives after the provider timeout, its effect can still commit but that late response does not cancel retries.
- Idempotency atomically permits one effect per event ID, including concurrent completions. It has no expiration, storage failure or timing overhead here.
- Extra-copy probability schedules at most one additional provider copy 1 second after creation, within the age limit. That copy has no retry chain. A timely acknowledgement can cancel queued main retries, but cannot undo in-flight work.
- Retry age limits new attempts; already-started attempts can complete later. Backoff is capped at 60 seconds per delay. Pending events are not assumed lost at the simulation end.
- At most 6,000 original events, 6 retries per event and one extra copy are simulated locally. The backlog line samples roughly once per second; its peak is calculated from exact event transitions.
Understand Webhook Delivery Simulator
What this tool helps you understand
Explore a deterministic webhook delivery model with receiver failures, timeouts, retry delays, recovery, and idempotency. Inspect event timelines and compare acknowledged deliveries with actual processing to understand retries, duplicate side effects, and unresolved work.
When to use it
Use Webhook Delivery Simulator when engineering, backend, and api work raises questions about webhook simulator, webhook retries, and idempotency and you need a concrete view before making the next move.
How to read the result
Compare the shape and direction of different scenarios. The useful signal is how the result changes when an input changes, rather than one isolated number.
Assumptions and limits
This deterministic model explains retries, acknowledgements, recovery, and idempotency. It does not deliver webhooks or reproduce every queue, timeout, and receiver behavior in a production system.
Toolooo is part of Khizooology, created byKhizar Imtiaz (khizooo).