Retries & Retry Policy

Failed deliveries shouldn't be lost. HookSniff retries them automatically with exponential backoff.

The Problem

Webhook deliveries fail all the time. The receiver's server might be down, the network might be slow, or a deployment might be in progress. If you only try once, you lose the event.

But retrying blindly is also bad — if you retry immediately and aggressively, you overwhelm a server that's already struggling.

How HookSniff Handles Retries

HookSniff uses exponential backoff with jitter:

Exponential backoff — Each retry waits longer than the last (1s → 2s → 4s)
Jitter (0-25%) — Random variation prevents thundering herd when many deliveries fail simultaneously
Configurable — Customize per endpoint: max attempts, base delay, max delay, multiplier

Default schedule (5 attempts):

Attempt	Delay After Failure	Cumulative Time
1	~1 saniye	~1s
2	~2 saniye	~3s
3	~4 saniye	~7s

Platform default: 5 attempts. Configurable per endpoint from 1 to 100.

What Counts as a Failure?

Not all errors trigger retries. HookSniff distinguishes between retryable and non-retryable failures:

Retryable

5xx Server errors
429 Rate limited
408 Request timeout
Connection timeout (30s)
DNS failure
TLS handshake failure

Not Retried

400 Bad request
401 Unauthorized
403 Forbidden
404 Not found
Other client errors

Only 2xx responses are considered successful. Client errors (4xx except 429/408) indicate a problem with the request itself — retrying won't help.

Custom Retry Policy

Different endpoints have different needs. A critical payment webhook might need more retries than a low-priority notification. Configure per endpoint:

curl -X PUT https://hooksniff-api-1046140057667.europe-west1.run.app/v1/endpoints/ep_abc123/retry-policy \
  -H "Authorization: Bearer hr_live_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "max_attempts": 5,
    "base_delay_ms": 2000,
    "max_delay_ms": 600000,
    "multiplier": 2.0
  }'

Parameter	Default	Description
max_attempts	3	Max delivery attempts (1–100)
base_delay_ms	1,000	Base delay in milliseconds
max_delay_ms	3,600,000	Maximum delay cap (1 hour)
multiplier	2.0	Backoff multiplier (1.0 = linear, 2.0 = exponential)

Replaying Failed Webhooks

After a delivery is moved to the DLQ, you can replay it. This resets the attempt counter and re-queues with a fresh retry schedule:

curl -X POST https://hooksniff-api-1046140057667.europe-west1.run.app/v1/webhooks/wh_xyz789/replay \
  -H "Authorization: Bearer hr_live_YOUR_KEY"

You can also replay from the dashboard with one click. Use this after fixing the issue on the receiver's side.

When to Customize

Payment webhooks — Increase max_attempts to 5-10, payments are critical
Analytics events — Decrease to 1-2, not worth retrying aggressively
Slow receivers — Increase base_delay_ms to give them more recovery time
High-volume endpoints — Use higher multiplier to space out retries