Glossary
Retry & Backoff
The strategy webhook senders use when a delivery fails — repeated attempts with increasing delays to avoid hammering a recovering receiver.
When your endpoint returns a non-2xx status (or times out), the provider retries — but not immediately. The standard pattern is exponential backoff with jitter: 1 min → 5 min → 25 min → 2 hr → … capped at some maximum span (Stripe retries for 3 days, GitHub for 8 hours).
The backoff prevents thundering-herd: when your endpoint recovers, all stalled webhooks don't slam in at once. Jitter (random ±20%) spreads retry timing across receivers behind a shared infrastructure.
Your handler should return 2xx only after the work is durably persisted. Returning 200 then crashing means the event is lost forever — the provider thinks it succeeded.
How HookSense helps
HookSense delivers each callback an agent awaits with signature verification today; automatic retries with backoff and jitter for failed callbacks are coming soon — so a `wait_for_callback` survives a flaky downstream the way production providers do.
Get a free webhook URL