Delivery log

Every send is recorded, whether it succeeded or failed, so you always have a record of what went out and what came back. Find it under Webhook Notifier → Logs.

What's in the list

The log lists recent deliveries, newest first, with:

Column	What it shows
When	When the attempt was made
Status	Sent, Failed, Retrying, or Queued, with a colour dot
Source	The source that triggered it, by its friendly name
Summary	A short description of the event (e.g. the entry title)
Response	The HTTP status code the webhook returned

Each row links to a Details page, and - if you can manage rules - offers a Resend button (see below).

The detail page

Opening a delivery shows everything recorded about it:

• Its status, when it was sent, and which source triggered it.
• The rule and connection it used, linked so you can jump straight to them (if either has since been deleted, you'll see its old ID noted instead).
• The attempt number and the HTTP status returned.
• Any error message.
• The exact request payload that was sent (pretty-printed if it's JSON).
• The response body the webhook returned.

This is the first place to look when a notification didn't turn up the way you expected - the request and response together usually tell you why.

Statuses

• Queued - handed to the queue, not yet sent.
• Retrying - a send failed and is waiting for another attempt.
• Sent - delivered, and the webhook accepted it.
• Failed - all attempts were used up without success.

Retries

Sends are queued rather than made inline, so a slow or briefly unreachable webhook never holds up the request that triggered it. If a send fails, it's retried using Craft's normal queue back-off, up to the Max retries setting (default 5). Only after those are exhausted does a delivery settle on Failed.

Resending

The Resend button lets you send a delivery again without waiting for the original event to happen once more - handy after you've fixed a bad webhook URL, corrected a card, or want to re-fire something that failed.

There are two ways a resend can behave, and the plugin picks automatically:

• Re-rendered from the rule's current card. When the delivery has a saved context (anything sent from v1.5.0 onward) and its rule still exists, the resend re-renders the rule's current card or payload against that saved context. So any edits you've made to the rule since are picked up - fix the card, then resend to see the corrected version.
• Original payload, sent as-is. When there's no saved context to re-render with (older deliveries), or the rule has been deleted, the resend posts the exact original body again, so it comes through as it did the first time rather than blank.

The message after a resend tells you which of the two happened. A resend is logged as its own delivery, with "(resent)" noted on its summary.

How long the log is kept

Delivery rows are pruned automatically during Craft's garbage collection, keeping the most recent Log retention (days) worth (default 30). Raise or lower it in Settings.

Pruning only touches history

Your rules and connections are never affected by log retention - only the record of past sends. Note that a pruned delivery can no longer be resent, so raise the retention if you rely on resending older deliveries.