Full Answer

The 5-failure threshold is hard-coded in WooCommerce core — it isn't a configurable setting. When a webhook endpoint returns a non-2xx HTTP status or times out on 5 consecutive attempts, WooCommerce sets the webhook's status to "disabled" in the database and stops all delivery. No event is queued for later. No log entry alerts the admin. The events that should have fired are simply gone.

This design made sense when webhooks were used for low-stakes notifications, but it becomes a serious liability when webhooks carry conversion events to analytics or ad platforms. A temporary server outage, a firewall rule change, or an expired SSL certificate on the receiving end can trigger 5 failures in minutes — and then every purchase, refund, and order status change after that point disappears from the downstream system without any warning.

The practical fix is an intermediary delivery layer — a webhook proxy like Hookdeck or a managed server-side tracking pipeline that doesn't depend on WooCommerce's native webhook delivery mechanism at all. These tools add automatic retry logic with exponential backoff, failure alerting, and event persistence that WooCommerce doesn't provide out of the box. How many developer hours does GTM server-side setup actually require? covers the infrastructure cost of building this kind of event resilience from scratch.