How Shopify Silently Kills Your Webhook Subscriptions (And How to Prevent It)

ShopHooks — Wed, 18 Feb 2026 15:34:23 +0000

Here's something most Shopify app developers learn the hard way: Shopify will silently delete your webhook subscriptions if your endpoint fails — and it won't tell you.

No email. No notification. No entry in your Partner Dashboard. Just... silence.

The Shopify Webhook Retry Policy

When your webhook endpoint fails to respond with a 2xx status within 5 seconds, Shopify doesn't immediately give up. It retries. After the original delivery attempt plus 18 retries over roughly 48 hours, Shopify permanently removes your webhook subscription.

This is documented in Shopify's webhook troubleshooting docs, but it's easy to miss — and the consequences are severe.

Why This Is Worse Than a Regular Outage

Most server outages get noticed quickly — your app goes down, users complain, your monitoring catches it. But webhook endpoints are different:

They're passive. They only receive traffic when Shopify has an event to send. There's no user staring at a loading screen.
Failures are invisible. Shopify retries silently. There's no proactive notification about delivery failures.
The blast radius is delayed. The real damage — missing orders, unfulfilled shipments, broken inventory sync — shows up hours or days later.
Re-subscribing isn't automatic. Once Shopify removes the subscription, it stays removed until you manually re-register it.

A Real-World Scenario

Timeline of a silent webhook failure

🟢 Monday 9:00 AM
Everything works fine. Your orders/create webhook fires, your fulfillment system picks it up, customers get tracking emails.

🟡 Tuesday 2:13 AM
A routine deploy introduces a regression. Your webhook handler starts returning 500s. Shopify begins retrying silently. You're asleep.

🟠 Wednesday ~2 AM — 48 hours later
Shopify exhausts all 19 attempts. It silently deletes your webhook subscription. Your integration is now completely disconnected. Events still happen — they just have nowhere to go.

🔴 Wednesday afternoon — a customer complains
"Why hasn't my order shipped?" You check the logs. Nothing. You check Shopify Admin. The webhook subscription is gone. You've been missing every order for 30+ hours.

Why Generic Uptime Monitors Don't Catch This

"Just use UptimeRobot" is the usual advice. Here's why it's insufficient for webhooks:

UptimeRobot and Pingdom monitor availability. They send a GET request and check if your server responds with 200. That tells you "your server is up."

But webhook endpoints have different failure modes:

Your server might be up, but your webhook handler throws a 500 on POST requests
Your server responds fine to GET, but times out on the actual webhook payload processing
Your endpoint works, but Shopify already removed the subscription — so nothing is coming through

The gap: generic monitors tell you if your server is up. They don't tell you if your webhook integration is actually working.

What You Should Actually Monitor

For reliable Shopify webhook integrations, you need to check:

Endpoint health — Is the endpoint responding to the correct HTTP method (POST) with a 2xx status within Shopify's 5-second timeout?
Response time trends — Is your response time creeping up? A handler averaging 4.5 seconds today will start timing out next week.
Delivery gaps — If you normally receive 50 events per day and suddenly get 0, something is wrong even if the endpoint is "up."
Subscription status — Is the webhook subscription still registered in Shopify?

Prevention Checklist

1. Acknowledge immediately, process async

Your webhook handler must respond within 5 seconds. If you do heavy processing, acknowledge first:

// Node.js — acknowledge immediately, process async
app.post('/webhooks/orders-create', (req, res) => {
  // Respond to Shopify immediately
  res.status(200).send('ok');

  // Process the order in the background
  processOrder(req.body).catch(err => {
    console.error('Failed to process order:', err);
  });
});

2. Add a health check endpoint

// Go — simple health check handler
func healthCheck(w http.ResponseWriter, r *http.Request) {
    if err := db.Ping(); err != nil {
        http.Error(w, "db unhealthy", 503)
        return
    }
    w.WriteHeader(200)
    w.Write([]byte("ok"))
}

3. Implement idempotent webhook handlers

Shopify can send duplicate webhooks. Use the X-Shopify-Webhook-Id header to deduplicate:

# Python — idempotent handler
@app.route('/webhooks/orders-create', methods=['POST'])
def handle_order(request):
    webhook_id = request.headers.get('X-Shopify-Webhook-Id')

    if redis.exists(f'webhook:{webhook_id}'):
        return 'already processed', 200

    process_order(request.json)
    redis.set(f'webhook:{webhook_id}', '1', ex=172800)
    return 'ok', 200

4. Check your webhook subscriptions periodically

# List all registered webhooks for your Shopify app
curl -X GET \
  "https://your-store.myshopify.com/admin/api/2024-01/webhooks.json" \
  -H "X-Shopify-Access-Token: YOUR_TOKEN"

If the list comes back shorter than expected, you've already lost subscriptions.

Automated Monitoring with ShopHooks

After experiencing this failure firsthand, I built ShopHooks — a monitoring tool specifically designed for Shopify webhook endpoints.

✅ 60-second health checks using the same HTTP method Shopify uses (POST)
✅ Smart alerts via Slack and email with context about what failed and why
✅ AI health analysis that spots degradation trends before they become outages
✅ Recovery notifications when endpoints come back up

It's free for up to 3 endpoints (no credit card required), which covers most single-store integrations. Setup takes about 60 seconds.

Have you experienced silent webhook removal? I'd love to hear your war stories in the comments.

DEV Community: ShopHooks