Webhook Watchdog for WooCommerce

WooCommerce keeps a counter of failed deliveries on every webhook. After the fifth failure in a row, it sets the webhook’s status to disabled — and tells no one. No email, no admin notice, no record anywhere the store owner would normally look.

The story is always the same: the integration on the other end — Printful, a CRM, a warehouse, accounting — simply stops receiving orders, and the store finds out days later from a customer or an undelivered parcel. The webhooks screen says “Disabled”, with no explanation of when, why, or how many times this has already happened.

This module is that missing half.

Live demo

Test site: test.catcode.com.ua (WordPress 7.1 + WooCommerce 10.7). In the admin menu — Webhook Watchdog: a “Scan now” button, the time of the last run, and an incident log.

Telling example: on this same test site, the module found a genuinely broken webhook right after installation — “Order sync with CRM”, 6 failed deliveries, endpoint no longer exists. Nobody knew about it.

What the buyer sees

Nothing — and that’s correct. The module adds nothing to the storefront, doesn’t touch the cart, checkout, or customer emails, and doesn’t slow down any store page. It only works in the admin and on a schedule.

What the admin gets

Scheduled webhook checks — every 15 minutes, hourly, twice a day, or once a day, your choice. Plus a “Scan now” button for when you need a check right away.

Incident log — a separate screen with its own table: when found, which webhook, topic, delivery URL, how many deliveries failed, what was done, and the endpoint’s response. Filters by result: notified only, restored, endpoint down, limit reached, failed.

The log answers a question neither WooCommerce nor the integration’s own panel answers: how long has this integration been failing, and how often.

Emails are one digest per scan, not one email per webhook. When an endpoint goes down, it takes all its webhooks with it at once, and twelve identical emails at 3 a.m. teach people to filter the sender rather than fix the endpoint.

How it works, step by step

1. On schedule, the module asks WooCommerce which webhooks currently have status disabled (optionally also paused).
2. An incident is logged for each one: topic, URL, failure count, previous status.
3. In “notify only” mode, that’s the end of it — the store’s state doesn’t change, you just find out.
4. In restore mode, the module first checks whether the endpoint responds at all: a plain HEAD request, falling back to GET if HEAD returns 405.
5. If there’s no response, or a 5xx comes back, the webhook stays disabled, and the exact reason (down to the cURL error text) is logged and emailed.
6. If the endpoint is alive, the webhook is switched back on, and the failure counter is reset along with the status.
7. Incident records older than a configured period are deleted automatically.

The probe deliberately never replays the payload that failed to deliver. Resending a real order webhook to an endpoint whose state is unknown is exactly how a warehouse ends up shipping the same order twice. The probe only answers “is anyone listening at this address at all”, and that’s what decides whether it’s worth trying to re-enable.

Any HTTP response, including 4xx, counts as a sign of life: an endpoint that rejects a bare GET but accepts a signed POST is entirely normal, and it’s still proof the host is up.

What’s included in each licence

Free — detection and logging: scheduled scans, a full incident record, an email digest, manual scan, 30 days of history, plus up to two automatic restores per webhook per day.

Pro — automatic re-enabling of webhooks as the standard mode, configurable flapping protection (how many times a day one webhook can be restored, 0 = unlimited), and longer log retention (up to three years).

Pricing

The base version is free. Pro is 990 UAH per year per domain. Trial period — 7 days.

Technical requirements

• WordPress 6.2+ (tested on 7.1).
• WooCommerce 6.0+ (tested on 10.7).
• PHP 7.4+.
• Works with HPOS (custom order tables) and the block cart/checkout — compatibility explicitly declared.
• Checking an endpoint requires outbound HTTP requests from the site (standard WP HTTP API).

Under the hood

A dedicated incidents table — one row for every time a webhook was found disabled, with what was done about it. That’s something neither WooCommerce nor the integration’s panel has: a history that shows recurrence.

Resetting failure_count on restore isn’t cosmetic. WooCommerce compares the current counter against the threshold, so a webhook re-enabled with a counter still sitting at five dies again on the very next failure. That’s the exact mistake people make when they re-enable a webhook by hand.

Flapping protection counts actual restores, not mentions: a webhook that’s been reported ten times hasn’t used up any of its quota. Without this limit, a webhook whose endpoint is broken in a way the probe can’t see would keep resurrecting forever — in batches of five real requests each time.

The scan is wrapped so that a failure inside it doesn’t take down the WordPress task queue: a watchdog that dies with a fatal error would take every other scheduled store task down with it.

The module doesn’t touch order tables and sends nothing anywhere except an email to your own address and a probe to the delivery URL you set in WooCommerce yourself.

Installation

1. Plugins → Add New → Upload Plugin → zip → activate. WooCommerce must be active.
2. Webhook Watchdog will appear in the admin menu.
3. Leave it in “notify only” mode for a few days to see what’s actually happening in your store.
4. Then decide whether to turn on automatic restoring.

Version history

1.0.0 — first release: scheduled scan, incident log, email digest, manual scan, automatic restore with a prior endpoint probe, failure counter reset, flapping protection, retention.