Delivery Logs

Conduit records every delivery attempt for every webhook. The records cover real inbound emails and simulated test sends. The logs are the main tool for three jobs: to make sure that a delivery succeeded, to debug a failing endpoint, and to audit what Conduit sent to your account.

Viewing logs

In the web UI

  1. Open the webhook detail page (/app/webhooks/{id}).
  2. Click Logs. For a quick view of the last few attempts, scroll to Recent Deliveries instead.

The full logs page (/app/webhooks/{id}/logs) lists every attempt, newest first, with 20 entries per page. The sub-navigation has these filters:

Filter Shows
All Every attempt.
Success Only the attempts where the target returned 2xx.
Failure 4xx, 5xx, timeouts, and connection errors.

Using the API

GET /api/v1/webhooks/{id}/logs?page=1&page_size=50

For the full field list and the pagination details, see Delivery logs in the API reference.

What each column means

Column Description
Time The time of the delivery attempt, in the timezone of your account.
Sender The SMTP envelope sender (MAIL FROM). For a simulated entry, the synthetic sender that Conduit used.
Message ID The SMTP Message-ID header from the inbound email. Empty for a simulation.
Transaction ID The ID that Conduit gave to the received email and this delivery attempt. Empty for a delivery from before transaction IDs existed.
Status The HTTP status from your endpoint. ERR means that Conduit could not reach it (DNS, TLS, timeout, or a refused connection).
Duration The time in milliseconds, from the moment the request left Conduit to the arrival of the response.
Error A short error message, when the attempt failed before Conduit could record a status.

A SIM badge next to the sender means that the Simulate feature created the entry, and not a real inbound email.

Status color coding

Range Meaning What the sending MTA sees
2xx Success 250 OK. The MTA accepted the message.
4xx Permanent failure 550. The MTA bounced the message.
5xx or no status Transient failure 450. The sending MTA retries.

Getting Started → SMTP response codes documents how an HTTP status maps to an SMTP response. You can set your own mapping for each delivery with SMTP response headers.

Retention

Conduit keeps delivery logs for a fixed period and then deletes them automatically. On the hosted Conduit service the default is 30 days. A self-hosted instance sets the window with the CONDUIT_DELIVERY_LOG_RETENTION environment variable.

For long-term retention, for compliance or analytics, fetch the logs over the API on a schedule and store them in your own system.

Debugging delivery failures

Repeated entries with a 5xx status or ERR mean that Conduit answered 450 to the sending MTA. The MTA then retries on its own schedule, and each retry creates a new log entry. To stop the retry loop, correct the endpoint or return a stable 2xx. For finer control, see SMTP response headers.

If your endpoint runs but the Conduit logs show ERR, make sure that the target URL uses HTTPS with a publicly trusted certificate. Also make sure that your firewall does not block the source IP addresses of Conduit.

To make sure that a request came from Conduit, compare the logs of your own endpoint against the attempted_at timestamp. Then verify the X-Conduit-Signature header with your webhook secret.

Every delivery also carries an X-Conduit-Transaction-Id header. This header is unique to the received email. Record it on your side to match a request to the exact message that Conduit processed. The same ID appears in the Transaction ID column, and on the log messages that Conduit writes for that email.

Next steps