Troubleshooting webhook deliveries - nothing arriving, failures, and where to look

Nothing is being delivered at all

Check the consumer first. This is the cause in the overwhelming majority of “no deliveries” reports: the ocmlabs.webhook.trigger queue consumer is not running, so messages pile up in the queue and never go out.

# is the consumer running right now?
ps aux | grep "queue:consumers:start ocmlabs.webhook.trigger" | grep -v grep

# are messages piling up? (rows here mean undelivered queue backlog)
bin/magento queue:consumers:list | grep ocmlabs

If it is not running, see the Installation page: either Magento’s cron starts it via cron_consumers_runner (the default when your system cron is healthy), or you run it under a supervisor. Confirm Magento’s cron itself is running - no cron means no consumer, no retries, and no log pruning.

Also confirm the module’s master switch is on (Stores > Configuration > OCM Labs > Webhooks > General > Enabled) and the webhook itself is Enabled and scoped to the store view where the event fires.

Deliveries fail or retry forever

Open System > OCM Labs > Delivery Log and read the row for the failed attempt:

• HTTP code present (4xx/5xx) - your endpoint rejected the request. The response body column shows what it said. A 401/403 usually means the Authentication settings or secret on the webhook do not match what the receiver expects.
• No HTTP code, error message shows a timeout or connection error - the endpoint was unreachable within the configured timeout. Check the URL, DNS, and firewall; raise the Delivery timeout if the endpoint is legitimately slow.
• Status Failed with a template error - the payload template failed to render. Template errors are never retried because they are deterministic; fix the template (the error includes the line) and use Send Test to confirm before saving.
• URL rejected before sending - the SSRF guard blocked it. Private, loopback, and link-local addresses and plain http:// URLs are rejected unless the development-only Advanced flags allow them.

Retries follow delay = retry_base_delay * 2^(failed_attempt - 1) up to Max Attempts, then the delivery is marked Failed for good. All attempts of one delivery share a Delivery UID, so you can trace the full story of one event through the log.

Request body column is empty

That is the default: request bodies are stored only when Log Payloads is enabled in configuration. Turn it on while debugging an integration, reproduce, read the exact payload sent, then turn it back off - bodies can contain customer data.

The log file

The module writes operational errors (observer failures, consumer exceptions) to its own file:

var/log/ocmlabs_webhook.log

Check it when something fails before a delivery log row could be written - for example an exception while snapshotting event data.

Send Test works but real events do not arrive

Send Test is synchronous - it bypasses the queue entirely. If tests succeed but real events never arrive, that isolates the problem to the queue pipeline: the consumer is not running, or cron is unhealthy. See the first section.

Duplicate deliveries on the receiver

Working as designed: delivery is at-least-once. A retry after a timeout your endpoint actually served produces a legitimate duplicate. Dedupe on the X-Webhook-Delivery-Id header, which is identical across all attempts of one logical delivery.