What is a retry?
A retry is re-attempting a failed delivery. In webhook systems, retries happen on a backoff schedule (typically exponential) until the delivery succeeds or exhausts its budget. After exhaustion, the delivery moves to a DLQ.
Exponential backoff
Naive constant-interval retries (every minute, forever) overload downstream systems and don't recover from longer outages well. Exponential backoff doubles the wait between retries: 30s, 1m, 5m, 15m, 1h, 4h, 12h, 24h. Early retries catch transient blips; later retries catch longer outages without hammering recovering systems.
Most providers retry with backoff:
- Stripe — retries for up to 3 days
- GitHub — stores failed deliveries for manual or API-driven redelivery; automatic redelivery requires your own scheduled workflow
- Slack — retries 3 times: nearly immediately, after 1 minute, and after 5 minutes
- Shopify — retries failed deliveries up to 8 times in about 4 hours, then the subscription can be removed if failures continue
Why retries need idempotency
Every retry can produce a duplicate from the consumer's perspective. The first attempt might have succeeded but the response was lost; the retry hits the consumer again. Without idempotency, the consumer processes the same event twice.
For agents specifically, retries are expensive (tokens) and have side effects (tool calls). Idempotency at both the event layer and the agent's tool-call layer is the discipline that keeps cost and side effects bounded.
For the broader retry discussion: Webhook DLQs: design and recovery patterns.
Frequently asked questions
How long do the major providers retry for?
Stripe retries for up to three days. Slack retries three times — almost immediately, after one minute, and after five minutes. Shopify retries up to eight times over about four hours and can then remove the subscription. GitHub does not retry automatically at all; it stores failed deliveries for manual or API-driven redelivery.
Why do retries require idempotency?
Because every retry can look like a duplicate to the consumer — the first attempt may have succeeded with its response lost on the way back. For agents that is expensive twice over, since retries burn tokens and tool calls have real side effects.
What is Hooksbase?
Hooksbase is event infrastructure for AI agents. It ingests events over four channels — HTTP, email, HTML form, and scheduled cron — verifies them, routes them by rule, runs versioned Automations in the event path, and delivers them to HTTP and cloud destinations (AWS SQS, AWS EventBridge, GCP Pub/Sub, and S3-compatible storage) with retries, strict ordering, Standard Webhooks-compatible signing, deterministic replay, and a dead-letter path. It is a hosted service, runs on Cloudflare Workers, is operated at hooksbase.com, and is not affiliated with — and shares no code or ownership with — other similarly named webhook, hook, or tunnelling tools.
Related terms
- Idempotency
A property where performing an operation multiple times produces the same result as performing it once.
Read - DLQ (Dead-Letter Queue)
A holding area for messages that failed terminally so they can be inspected and recovered.
Read - Fan-out
Delivering one event to multiple consumers in parallel.
Read - Routing rule
A priority-ordered condition that selects which destination handles an event.
Read