Do not assess WooCommerce webhooks solely through a successful test. Periodically compare what your integration expects with what is actually configured in the online store. An endpoint may be reachable while a webhook is missing, paused, pointing to an old address or no longer listening to the right topic. The integration then appears healthy until an order stops moving.
Being reachable is different from being complete
A conventional uptime check makes an HTTP request and concludes that the server responds. For a webhook integration, that answers only one question. You also want to know whether every required registration is present, whether its status is active and whether its topic and delivery URL match the local configuration. An API error while reading the configuration must not be confused with a missing webhook either.
A mature health check therefore builds an expected set from the enabled workflows. An organisation that only synchronises orders needs different webhooks from one that also processes refunds or stock events. This prevents both false alarms about unused topics and silence when a necessary registration disappears.
Four statuses that need an owner
| Status | Meaning | First action |
|---|---|---|
| Active and matching | The remote registration matches | Continue checking periodically |
| Paused | The registration exists but is not delivering | Investigate the reason and reactivate deliberately |
| Missing or different | The expected registration is not usable | Restore the configuration and test with a trial order |
| API error | Health cannot be determined | Check authentication, permissions and connectivity |
Do not turn these statuses into a technical dashboard that nobody checks. For each alert, record the affected shop, workflow, webhook topic and time. Send the warning to a specific owner and show how long the condition has lasted. That makes integration management in Connect useful for operations as well as developers.
Fictional example: the silent order flow
Fictional example: after online store Veluwe Vitaal is migrated, the old webhook address remains in WooCommerce. The new integration environment responds perfectly to manual tests but receives no new orders. A comparison finds that the expected topic exists, but with a different URL. The status becomes “different” and the administrator sees the exact registration.
After correcting it, the team places a trial order and follows the complete route: received event, validated order, ERP processing and any subsequent logistics action. The team only marks the incident resolved once it has also established which orders were missed during the gap. That may require a scoped comparison with the source or controlled reprocessing. A green icon after recovery says nothing about the historical backlog.
A health check for every change
- Derive the required webhook set from the processes that are actually enabled.
- Compare topic, status and delivery URL; never compare counts alone.
- Retain the time and result of the last successful check.
- Distinguish between “missing” and “could not check”.
- After recovery, check for missed orders as well as new arrivals.
- Repeat the check after changes to domains, plugins, keys or environments.
Combine this with process monitoring as described for online store–ERP integrations. If an order still does not get through, Desk helps make the failed step and next action visible instead of treating the customer enquiry separately from the technology.
Finally, distinguish between detection and automatic recovery. Recreating a missing registration may seem convenient, but during a deliberate migration or a change to security settings it could reintroduce an error. A safe default is to detect the difference, show the expected and actual records, let an authorised administrator confirm the recovery and then check a real process. Also record who may change online store URLs, secrets and webhook topics. This turns the health check into a change check: after every release or infrastructure change, you can see whether the contracts between the two sides still match. Include the measurements in incident reviews so recurring discrepancies lead to a lasting adjustment instead of the same manual work every time.
Also retain a limited history of checks. A single snapshot tells you something is different now; the sequence shows when the difference began and whether it coincided with a release. That makes the investigation considerably shorter. Agree a reasonable checking frequency based on order volume and risk, and avoid emailing everyone about the same unchanged warning every fifteen minutes.
Want a webhook check that fits your active order processes? Discuss the expected set and escalation with Yindle.