Webhook Monitoring for E-commerce
Shopify removes a webhook subscription after roughly four hours of failures. On a peak trading day that is a year of ordinary orders.
E-commerce webhook failures concentrate their damage into short windows, which is what makes them different from most integration problems. A four-hour gap in March costs you a handful of orders. The same gap on your biggest trading day can cost more than a normal month.
The Shopify subscription removal problem
Shopify retries a failing webhook around eight times over roughly four hours, and if failures persist it removes the subscription. That is the part worth internalising: you do not lose the events from the outage, you lose every future event of that topic until somebody re-registers it.
A deploy at 18:00 on Friday that breaks your handler has exhausted its retries before 22:00. By Saturday morning the subscription is gone, orders keep arriving in Shopify, and nothing reaches your system. Your store looks perfectly healthy from the customer's side.
Much of the advice online still says 19 retries over 48 hours. That figure is out of date and planning around it gives you roughly twelve times the recovery window you actually have.
What each missed topic actually costs
| Missed topic | Immediate consequence | How you normally find out |
|---|---|---|
| orders/create | Paid order that does not exist downstream | Customer asks where their parcel is |
| inventory_levels/update | Overselling stock you do not have | Cancellations and refunds days later |
| orders/fulfilled | Tracking never sent to the customer | Support tickets |
| refunds/create | Accounts disagree with the platform | Month-end reconciliation |
| customers/data_request | Compliance obligation missed | Escalation from the platform |
Overselling deserves particular attention because it damages the relationship rather than just the order. A customer who never receives an order they paid for is a refund. A customer told three days later that the item was never in stock is a review.
The multi-system problem
Most stores past their first year are not running one integration. There is the storefront platform, a payment processor, a 3PL or warehouse system, an ERP or accounting package, an email platform, and often a marketplace channel or two.
Each of those has its own webhooks, its own retry policy and its own dashboard. Nobody looks at six dashboards. The practical approach is to monitor the handful of paths where a break costs money directly, and accept slower detection on the rest.
For most stores that shortlist is order ingestion, inventory sync, and fulfilment status. Everything else can wait for a daily reconciliation.
Sizing alerts around your actual order rhythm
Interval-based alerting only works if the interval reflects your real trading pattern. A store doing 30 orders a day has overnight gaps of eight hours or more, and a two-hour alert threshold will page you every single night.
Run that query, take the result, and add margin. Then raise the sensitivity during known peak periods, because a one-hour gap on Black Friday is a genuine emergency and the same gap in February is a slow Tuesday.
Before peak season
Re-register and verify every webhook subscription in the week before your busiest period, confirm the handler responds well under the platform timeout, and check that whoever gets the alert is actually available. The most expensive outage in e-commerce is the one that starts while everyone is asleep on the highest-revenue night of the year.
SensaCat watches order flow for the gap that means ingestion has stopped, and covers the certificate and credential expiries that break integrations without any warning. Start free.
Setup detail is in how to monitor Shopify webhooks.