Over the past week, I’ve started seeing some webhook delivery errors in my Shopify app with the same message:
“No response from app Error”
It happens around 2–5 times per day. I don’t remember seeing this before.
My app has a pretty low webhook volume, around 3,000 webhooks per day. I also use a separate server only for handling webhooks. The mean response time is around 300ms, and I checked CPU never goes above 6%, and RAM usage stays below 30%.
So I’m not sure if this is an issue on my side or something else.
Has anyone noticed similar webhook errors recently?
Hi @KyleG-Shopify, I’d like to add more details after tracing this further.
I checked many webhook IDs that Shopify marked as `No response from app Error` with `6000ms` in the dev dashboard, and they all show a similar result in my Nginx logs.
For example: shopify_webhook_id="2a626a18-dd6c-5a35-9965-4945ed8318bc" shopify_topic="customers/update" status=200 upstream_status=200 request_time=0.014 upstream_response_time=0.014 request_completion=OK
Shopify retried the same webhook ID about 7 seconds later, and that retry also completed with 200 in 0.008s.
So from my Nginx logs, the first attempt appears to have reached my app and completed successfully, but Shopify still recorded it as no response.
This is happening across multiple topics, including products/update, shop/update, and customers/update.
Could someone from Shopify help check why these deliveries are being marked as no response even though Nginx shows they completed successfully? This is now happening very frequently for my app, with over 100 such errors per day.
Can you look at the X-Shopify-Triggered-At header on the webhook requests that were marked as failed, and compare that timestamp to when your server actually received the request. The reason I ask is even if your app processes the webhook quickly, connection establishment, TLS negotiation, and network routing all count against the 5-second request timeout, so the response could be arriving after our timeout already fired.
If there’s a meaningful gap between those two, that confirms the delay is happening in transit before your server even starts processing.
On the best practices side, there are a few things worth confirming. Our delivery system uses HTTP Keep-Alive to reuse connections, so if that’s not enabled on your Nginx config, every delivery requires a fresh connection (DNS, TCP handshake, TLS), which eats into the timeout budget. Your webhook handler should also be returning the 200 response before doing any processing work. Database writes, API calls, or anything else should happen asynchronously via a queue so that time doesn’t count against the 5-second window. And since you’re already seeing retries for webhooks your server processed successfully, using the X-Shopify-Webhook-Id header to deduplicate deliveries will prevent double-processing.
I haven’t seen any new errors in the last 24 hours. I’ll add X-Shopify-Triggered-At to my Nginx logs and compare it with the server receive timestamp if the issue happens again.
My handler already returns 200 immediately and dispatches the processing asynchronously. I’ll also verify the Keep-Alive configuration and webhook ID deduplication.