# Webhook delivery ops: be idempotent, be fast, know the retry schedule
If your endpoint does not return HTTP 200, Resend retries with exponential backoff: immediate, 5 seconds, 5 minutes, 30 minutes, 2 hours, 5 hours, 10 hours.
## Steps
1. Make every handler idempotent. Dedupe on the svix-id header (unique per message) or the event id before doing any side effect: check your processed-events store first, record it, then act. Retries and replays will redeliver the same event.
2. Return 200 quickly, then process asynchronously. A slow handler that times out triggers a retry of work that already succeeded, which is how duplicate emails and double-charged follow-ups happen.
3. Return non-200 only when you genuinely failed and want a retry. Returning 200 for an event you cannot handle yet is a lie; fix the handler instead.
4. When events go missing, debug with the delivery history API: list events on the webhook, inspect each attempt's HTTP status code and response body, and replay the event from the dashboard or API to reprocess it with fixed handler code.
## The trap
A handler that is neither idempotent nor fast. The retry schedule will redeliver into it for 10 hours, and every redelivery re-runs your side effects. The other trap is treating a replayed event as suspicious: replays are a normal operations tool, and your idempotency dedupe is what makes them safe.