Delivery Logs
Conduit records every delivery attempt for every webhook, covering both real inbound emails and simulated test sends. Logs are the primary tool for confirming a delivery succeeded, debugging a failing endpoint, and auditing what was sent to your account.
Viewing logs
In the web UI
- Open the webhook detail page (
/app/webhooks/{id}). - Click Logs, or scroll to Recent Deliveries for a quick view of the last few attempts.
The full logs page (/app/webhooks/{id}/logs) lists every attempt in
reverse-chronological order, paginated 20 per page. The sub-nav has filters:
| Filter | Shows |
|---|---|
| All | Every attempt. |
| Success | Only attempts where the target returned 2xx. |
| Failure | 4xx, 5xx, timeouts, connection errors. |
Using the API
GET /api/v1/webhooks/{id}/logs?page=1&page_size=50
See Delivery logs in the API reference for the full field list and pagination details.
What each column means
| Column | Description |
|---|---|
| Time | When the delivery was attempted, shown in your account's timezone. |
| Sender | The SMTP envelope sender (MAIL FROM). For simulated entries, the synthetic sender Conduit used. |
| Message ID | The SMTP Message-ID header from the inbound email. Empty for simulations. |
| Status | HTTP status returned by your endpoint, or ERR if Conduit could not reach it (DNS, TLS, timeout, connection refused). |
| Duration | Time from the request leaving Conduit to the response arriving, in milliseconds. |
| Error | Short error message when the attempt failed before a status could be recorded. |
A SIM badge next to the sender means the entry was created by the Simulate feature, not a real inbound email.
Status colour coding
| Range | Meaning | What the sending MTA sees |
|---|---|---|
2xx |
Success | 250 OK. Message accepted. |
4xx |
Permanent failure | 550. Message bounced. |
5xx or no status |
Transient failure | 450. Sending MTA will retry. |
The mapping from HTTP status to SMTP response is documented in Getting Started → SMTP response codes and can be customised per delivery using SMTP response headers.
Retention
Delivery logs are kept for a fixed period and then automatically purged. On
the hosted Conduit service this is 30 days by default. Self-hosted
instances control the window with the CONDUIT_DELIVERY_LOG_RETENTION
environment variable.
If you need long-term retention for compliance or analytics, fetch logs over the API on a schedule and store them in your own system.
Debugging delivery failures
Repeated entries with status 5xx or ERR mean Conduit responded 450 to
the sending MTA, which then retries on its own schedule. Each retry produces a
fresh log entry. To stop the retry loop, fix the endpoint or return a stable
2xx. For finer control, see SMTP response headers.
If your endpoint is up but Conduit logs show ERR, check that the target URL uses HTTPS with a publicly trusted certificate, and that Conduit's source IPs are not blocked at your firewall.
To confirm a request actually came from Conduit, cross-reference your
endpoint's own logs against the attempted_at timestamp and verify the
X-Conduit-Signature header with your webhook secret.
Next steps
- Testing Webhooks. Generate a delivery on demand.
- Managing Webhooks. Deactivate, rotate, or delete a webhook.
- Using the API. Fetch logs programmatically.