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

  1. Open the webhook detail page (/app/webhooks/{id}).
  2. 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