Retry behavior
Delivery retry schedule, dead-letter policy, and idempotency
RevKeen retries failed webhook deliveries automatically. Your consumer just needs to be idempotent and return 2xx quickly on success.
Retry schedule
A delivery is considered failed if your endpoint returns non-2xx, times out after 30 seconds, or refuses the connection.
| Attempt | Delay after previous failure |
|---|---|
| 1 | Immediate (the original delivery) |
| 2 | 5 minutes |
| 3 | 30 minutes |
| 4 | 2 hours |
| 5 | 8 hours |
| 6 | 24 hours |
After 6 attempts RevKeen stops retrying and marks the delivery as dead. Dead deliveries are visible on the endpoint in the dashboard for 30 days before archival.
What counts as a failure
| Response | Retried? |
|---|---|
2xx | No — success. |
3xx | Yes — treat as a failure. Do not redirect. |
4xx | Yes — but consider it a bug on your side; alert. |
5xx | Yes. |
| Timeout (>30s) | Yes. |
| Connection refused / DNS failure | Yes. |
| TLS handshake failure | Yes. |
Idempotency contract
Every delivery attempt uses the same event id. Retries do not produce new event IDs.
{ "id": "evt_1a2b3c4d5e6f", "type": "payment.succeeded", "created": 1705689600, ... }Your consumer should:
- Extract
event.idon receipt. - Check a persistent store (Redis, DB, idempotency table).
- If the ID is new → process and persist the ID.
- If the ID is known → return
2xxwithout reprocessing.
This is the same idempotency pattern used by the REST API — events and API mutations share the guarantee.
Ordering guarantees
Deliveries across different resources are not ordered. subscription.renewed and the matching invoice.paid may arrive in either order, seconds apart.
Deliveries for the same resource are mostly ordered — e.g., subscription.created before subscription.updated — but do not rely on strict ordering for correctness. Always reconcile against the current resource state via a GET before acting on stale assumptions.
Dashboard tools
The endpoint detail page exposes:
- Deliveries tab — every attempt with request + response bodies, timing, and status.
- Retry button — manually re-fire a dead delivery after you fix your consumer.
- Replay — resend any past event to your current endpoint without affecting production traffic.
Monitoring your endpoint
- Alert on dead deliveries via the
endpoint.delivery.failedevent type or dashboard webhooks. - Alert on elevated retry rates — if more than 1% of deliveries are retrying, something is wrong.
- Track p99 response time — if you consistently take >5 seconds, queue async and return
2xximmediately.