Delivery lifecycle
Every time a subscribed event fires, DeepSmith creates a delivery for each active webhook that matches the event type. Each delivery follows this lifecycle:Delivery statuses
| Status | Description |
|---|---|
delivered | Successfully delivered on the first attempt |
recovered | Failed initially but succeeded on a retry attempt |
failed | All 3 attempts failed |
pending | Delivery is queued or in progress |
Retry policy
Failed deliveries are retried automatically with exponential backoff:| Attempt | Delay | Total elapsed |
|---|---|---|
| 1st | Immediate | 0s |
| 2nd | 10 seconds | ~10s |
| 3rd | 60 seconds | ~70s |
A delivery is considered failed when your endpoint returns a non-2xx HTTP status code, the connection times out (15 second limit), or a connection error occurs.
failed and the webhook’s consecutive_failures counter is incremented.
Auto-disable
When a webhook accumulates 10 consecutive failures, it is automatically disabled to protect your endpoint from unnecessary traffic. When a webhook is auto-disabled:- Its status changes to
DISABLED - No further deliveries are sent
- You can re-enable it from Settings > Webhooks, which resets the failure counter
Viewing delivery history
Open a webhook from Settings > Webhooks and navigate to the Deliveries tab. You can filter deliveries by event type and status (delivered, failed, recovered).
Sample delivery log
Delivery fields
| Field | Type | Description |
|---|---|---|
id | uuid | Delivery ID |
webhook_id | uuid | Parent webhook ID |
event_type | string | Event type that triggered this delivery |
payload | object | Full payload that was sent |
http_status | integer|null | HTTP response status (null for connection errors) |
response_body | string|null | Response body (truncated to 2048 chars) |
response_time_ms | integer|null | Response time in milliseconds |
attempt | integer | Which attempt this was (1, 2, or 3) |
max_attempts | integer | Maximum attempts (always 3) |
delivery_status | string | Computed status: delivered, recovered, failed, or pending |
successful | boolean | Whether the delivery succeeded |
is_test | boolean | Whether this was a test delivery |
delivered_at | datetime | When the delivery was attempted |
created_at | datetime | When the delivery was created |
Retrying a failed delivery
From the delivery log, click Retry on any failed delivery. This re-queues the delivery with the original event type and payload. The new attempt appears as a separate entry in the delivery log.Only failed deliveries can be retried. The retry button is not available for successful deliveries.
Performance stats
The webhook detail page shows performance charts for Event deliveries (total vs. failed) and Response time (min, avg, max). You can switch between three time periods:| Period | Bucket size | Description |
|---|---|---|
| Last 24 hours | Hourly | Good for investigating recent issues |
| This week | Daily | Default view for ongoing monitoring |
| Last 30 days | Daily | Long-term health overview |
Sample stats response
Best practices
Respond quickly
Respond quickly
Return a
200 status code as fast as possible. Process the webhook payload asynchronously (e.g., queue a background job) rather than doing heavy work in the request handler. DeepSmith enforces a 15-second timeout.Handle duplicates
Handle duplicates
Use the
X-Webhook-Delivery header to deduplicate deliveries. Your endpoint may receive the same event more than once due to retries.Monitor your error rate
Monitor your error rate
Check the
error_rate on your webhooks and the performance charts regularly. A rising error rate indicates your endpoint may have issues.Use a queue
Use a queue
Don’t process webhooks synchronously. Push them onto a queue (SQS, Redis, RabbitMQ) and process them asynchronously. This keeps your endpoint responsive and prevents timeouts.
Log everything
Log everything
Log incoming webhook payloads and your processing results. DeepSmith’s delivery history shows what was sent, but your logs capture how your application handled it.