WooCommerce webhook failures can become especially dangerous when an external ERP or order-management endpoint is temporarily unreachable. In this case, orders were charged successfully but were not delivered to the downstream system, and no failure alert was sent. The custom integration failed before its retry-and-alert logic could run. Updating the integration to retry network-level failures up to three times and send an alert after the final failure prevented future orders from disappearing silently.
Issue background
A WooCommerce store used a custom integration to send new orders to an external ERP system. During two separate outages, the ERP endpoint stopped accepting connections for a period of time.
WooCommerce continued creating and charging orders, but the affected transactions were not delivered to the ERP. The expected webhook-failure notification was also missing, so the problem was discovered only after reviewing order activity manually.
After several hours of consecutive failed deliveries, WooCommerce automatically disabled the webhook. Once the webhook was disabled, new orders were no longer attempted at all.
Diagnosis
The failure occurred only when the external endpoint was unreachable at the network level, such as a timeout or refused connection.
Normal successful deliveries and normal error responses from the ERP were not affected. The custom plugin already had retry and alert logic for handled delivery failures, but the network exception occurred earlier in the request flow and caused the handler to stop before that logic could execute.
This created three connected problems:
- The order was not delivered to the ERP.
- The delivery was not retried.
- No failure notification was sent.
WooCommerce then applied its built-in safety behavior. After enough consecutive failed deliveries, it automatically changed the webhook status to disabled. The WordPress activity log confirmed that the change was made by WooCommerce System rather than by a logged-in administrator.
A separate Divi cache error appeared during the investigation, but it was unrelated to the ERP delivery failure. Clearing the Divi cache resolved that independent issue.
Resolution steps
- Identify the affected delivery window. Compare WooCommerce order timestamps with the external system’s received-order records to determine which transactions require manual resending.
- Preserve evidence before resending. Capture webhook logs, order notes, request timestamps, and endpoint responses so the root cause can still be investigated after orders are recovered.
- Confirm the webhook status. Check WooCommerce → Settings → Advanced → Webhooks and verify whether WooCommerce automatically disabled the integration.
- Review the activity log. Use WP Activity Log or an equivalent audit tool to determine whether the webhook was disabled by a person or by WooCommerce System.
- Separate network failures from HTTP error responses. Test timeouts, refused connections, DNS failures, and other transport-level exceptions in addition to ordinary 4xx and 5xx responses.
- Move network exceptions into the normal failure path. Ensure that connection errors are caught and processed by the same retry and alert logic used for handled delivery failures.
- Add bounded retries. The updated custom integration retried a failed delivery up to three times rather than abandoning the order after the first network error.
- Alert after the final failed attempt. Send a clear notification containing the order reference, timestamp, endpoint, and failure type when all retries are exhausted.
- Test by simulating an unreachable endpoint. On staging, block or replace the ERP endpoint so the request times out or refuses the connection. Confirm that the order retries and that the alert is sent.
- Verify normal deliveries. Restore the valid endpoint and confirm that the retry changes do not affect successful order transmission.
- Deploy with rollback available. The fix was released as version 2.2.0 of the custom integration, while the previous stable version remained available for immediate rollback.
- Re-enable the webhook when necessary. After confirming that the endpoint is reachable, manually re-enable a webhook that WooCommerce has disabled and resend the affected orders.
- Add an independent webhook-status monitor. A delivery-failure alert cannot run after the webhook is disabled because no new delivery attempt occurs. Use WP-Cron or a server-side scheduled task to check the webhook status and notify administrators when it becomes disabled.
- Monitor after deployment. Review webhook delivery logs, order notes, and ERP receipt records to verify that all new orders are transmitted correctly.
Retry logic should be bounded and observable. Unlimited retries can create duplicate orders or overwhelm an unavailable service, while silent failures leave the business unaware that fulfillment has stopped.
Final outcome
Version 2.2.0 of the custom WooCommerce integration was deployed to production. Network-level connection failures were brought into the standard error-handling path, allowing the system to retry each delivery up to three times and send an alert if the endpoint remained unreachable.
The previous plugin version was retained as a rollback option, and the obsolete build was removed from the server.
The deployment restored reliable failure notifications for active webhook delivery attempts. The investigation also identified an additional safeguard for future work: a separate scheduled monitor is needed to alert administrators when WooCommerce has already disabled the webhook, because a disabled webhook produces no new delivery attempts and therefore cannot trigger the plugin’s normal failure notification.
The key lesson is that WooCommerce integrations must handle transport failures as carefully as application-level errors. Timeouts and refused connections should never bypass retry, logging, and alerting logic.
For help troubleshooting WooCommerce webhooks, improving ERP integrations, or adding reliable retry and alert systems, contact Freshy.
