Delivery log and replay

Every time Aloft sends a notification through a webhook-shaped channel — webhook, Slack, Discord, Microsoft Teams, PagerDuty, OpsGenie, or SMS — it records the attempt. You’ll find the record under Alerts in the top navigation, on the Deliveries tab.

This is your audit trail and your debugging tool: it shows what went out, what the receiver said back, and lets you re-send an event after you’ve fixed something on the other end.

Reading the log

The Deliveries tab lists the latest 200 attempts, newest first. Each row shows:

• Channel name and type (e.g. webhook, slack).
• Kind — whether the notification was a down, up, or test event.
• Status — the HTTP status code the receiver returned (e.g. 200), or ERR if the request failed before any response came back.
• Target URL — where the request was sent.
• Error message — populated only when the delivery failed.
• Time sent and the response time in milliseconds.

Note

Email notifications aren’t listed here. The delivery log covers the webhook-style channels that share Aloft’s outbound HTTP path.

Spotting a failed delivery

A delivery is flagged as failed when either:

• the receiver returned an HTTP status of 400 or higher, or
• the request errored before getting a response (shown as ERR).

Failed rows carry a red status badge and, when available, a one-line error message under the target URL. Common causes:

• A 4xx status (e.g. 401, 404) — the receiver rejected the request. Check that the webhook URL, token, or routing key is still valid.
• A 5xx status — the receiver is up but erroring. Usually a problem on their end; retry once they recover.
• ERR with a “Refused” message — Aloft declined to send the request because the target resolved to a private or internal address. Point the channel at a publicly reachable URL.
• ERR with a timeout — the receiver didn’t respond in time (Aloft waits up to 10 seconds per request).

The response time is handy too: a row that’s fine but slow can point at a struggling receiver before it starts outright failing.

Replaying a delivery

When you’ve fixed a receiver — corrected a webhook URL, rotated a token, restarted a downstream service — you don’t have to wait for the next real outage to confirm it works. Select Replay on any delivery row to send the event again to the same channel.

What replay does depends on the channel type:

• Webhook and SMS channels re-send the original event payload. For a signed webhook, Aloft re-signs the replay with a fresh timestamp and nonce, so a correctly-configured receiver accepts it instead of rejecting it as a stale replay (see Webhooks and signing).
• Slack, Discord, Teams, PagerDuty, and OpsGenie channels get a freshly synthesized alert of the same kind (up or down), so the provider sees a realistic resend.

A replay creates a new row in the delivery log, so you can immediately see whether the re-sent attempt succeeded.

Tip

To validate a brand-new channel before any real traffic, use Send test on the Channels tab instead — it fires a synthetic alert and shows up here as a test delivery. See Channels.

Where to go next

• Channels — set up and test channels.
• Webhooks and signing — verify webhook authenticity and understand replay re-signing.