stop-slop

Webhook deliveries fail for reasons that are usually temporary: the receiving server is restarting, a deploy is in progress, a network blip drops the connection, or the endpoint is briefly overloaded and returns a 503. If we gave up after one attempt, customers would silently miss events like payments or status changes, and they'd have to build their own reconciliation to catch the gaps. Retrying gives us at-least-once delivery, so most transient problems resolve without anyone getting paged or filing a ticket. We space those retries out with exponential backoff (for example, waiting a little longer after each failure) rather than hammering the endpoint at a fixed interval. If a receiver is struggling, a flood of immediate retries can keep it down, and with many failing deliveries at once, we could create a retry storm that hurts both the customer and our own queues and workers. Growing delays give the receiver time to recover, spread load over time, and keep our resource usage bounded. Most implementations also add random jitter so retries from many events don't all land at the same instant, and a maximum attempt count or time window so we eventually stop and surface the failure, such as through a dead-letter queue or a dashboard alert. Because retries mean a receiver may see the same event more than once, it's also worth remembering that events should carry a stable ID so consumers can deduplicate them.