Events & retries
Understand the full lifecycle of a webhook event — from ingestion to delivery — and how HostWebhook handles failures automatically.
Event lifecycle
Every event passes through the following states:
Event received and queued, not yet attempted.
Delivery attempt is in progress.
Your server responded with 2xx. Done.
Last attempt failed; waiting for the next retry.
All retries exhausted, or manually canceled. The event will not be retried automatically.
Event was discarded by a payload filter rule — no delivery was attempted.
Event failed schema validation — blocked before delivery by a Schema Validator node.
Event is held at an Approval Gate — waiting for manual approve/reject.
Event is paused at a Delay node — will resume after the configured delay.
Retry schedule
A retry is an additional delivery attempt after a failure — it does not count the initial attempt. Configuring maxRetries: 3 means HostWebhook tries once initially and up to 3 more times, for 4 total attempts.
Retries use capped exponential backoff: delay = min(retryDelaySeconds × 2^(retry - 1), cap). With the default retryDelaySeconds: 60:
| Retry | Delay (default 60 s base) |
|---|---|
| 1st | 60 s (1 min) |
| 2nd | 120 s (2 min) |
| 3rd | 240 s (4 min) |
| 4th (Pro+) | 480 s (8 min) |
| 5th (Pro+) | 960 s (16 min) |
Replaying events
You can manually replay any event from the dashboard — whether it's failed, delivered, or canceled. Replaying:
- Creates a new delivery attempt immediately
- Uses the same original payload (no re-ingestion)
- Resets the retry counter — a replayed event gets the full retry budget again
- The original
X-Webhook-Event-Idis preserved — use it to deduplicate on your server
You can also replay all failed events for an webhook at once from the webhook detail page. Useful after fixing a downstream outage.
Canceling events
Pending or retrying events can be canceled from the dashboard. This stops all future delivery attempts. Cancellation is permanent — use replay if you change your mind.
Event history
Events are retained for the duration of your plan:
| Plan | History | Max retries |
|---|---|---|
| Free | 7 days | 3 |
| Pro | 30 days | 10 |
| Enterprise | 90 days | Unlimited |
Filtering the event list
The event list in the dashboard supports filtering by:
- Status — delivered, failed, retrying, filtered, etc.
- Event type — the value of a top-level
typeoreventfield in your payload - Date range — narrow to a specific time window
Payload filters (pre-delivery)
Payload filters are rules you configure on a webhook to discard events before any delivery is attempted. Events that fail the rules are saved with status filtered — they appear in the event list but no delivery job is ever created for them.
This is different from the dashboard's list filters above, which only narrow your view. Payload filters act at ingestion time and are permanent.
Configure payload filters on a webhook →Dead Letter Queue (DLQ)
Events that exhaust all retries are moved to the Dead Letter Queue. DLQ events have status failed and remain visible in the event list with a DLQ badge. You can:
- View all DLQ events for a webhook from the webhook detail page
- Manually replay individual events or bulk-replay all DLQ events
- Configure auto-replay to automatically retry DLQ events after a cooldown period
Pipeline statuses
Events processed through the canvas pipeline may acquire additional statuses beyond the standard lifecycle:
SCHEMA_INVALIDBlocked by a Schema Validator node — the payload did not match the required fields. No delivery is attempted.AWAITING_APPROVALHeld at an Approval Gate node — requires manual approve or reject before continuing through the pipeline.DELAYEDPaused at a Delay node — will automatically resume and continue delivery after the configured delay (in seconds).