Is it common to see a webhook request made in the Shopify logs that does not show up in your server logs? I don’t see many, but I do see a few. Now, Shopify does retry so no big deal, but I’m wondering if this is something other apps see as well.
Hey, I have a similar issue, you may want to take a look:
Thanks @parker … but you’re actually getting those webhooks? These are webhook requests that never actually hit my server - I have no log of them. Now, I get what I think is a lot of webhooks each day - about 30-40k+ and only like 10 (yes, just 10) or so failures, but it’s not actually getting some of these that bother me.
I do have the same failures you mentioned too, but they don’t actually hit the time out before saying there was no response. They end in roughly 1 second according to the Shopify record and I see the request/response handshake at normal timings, but they still report they didn’t get a response.
hey @Doug_P
I think your issue may actually be very similar to mine.
What are you using to log the requests that hit your server?
In my case, my application logs showed that the webhook requests Shopify marked as “no response from app” were still processed very quickly. After that, I added logging at the Nginx level as well, and those requests also looked normal there.
The strange thing is that I haven’t seen any of these webhook failure logs in the last 48 hours. So I’m starting to think the issue may have been on Shopify’s side, and somehow it has been fixed recently.
HTTP web logs is what I’m using. There’s no indication some of these errors even hit my server.
hey @Doug_P, do you find the request by webhook id?
In my logs? No, it’s not actually hitting my servers. That’s the problem. Because I have no record of some webhooks not hitting my servers, but erroring out on Shopify’s end I was wondering if anybody else saw those.
See, this could be a problem of exposure - maybe there are enough requests that I’m playing the odds game - odds are that a few are dropped each day. But I want to make sure it’s not a connectivity issue that Shopify can’t actually hit my servers on small occassion.
I think what I’m going to do is separate the webhooks from the main app into it’s own service. This way I can process the multitude of workers without it being affected by the main app in any sort of way.
oh, that’s actually weird :'D mine is 6000ms
KyleG should have a look on this
Hey @Doug_P - thanks for laying this out so clearly, and @parker for the context as well
I think you’re each seeing a different failure mode, so it’s worth separating the two.
@parker’s 6000ms case looks to me like a true timeout. Apps have a 5 second window to respond, and anything past that is recorded as a failure even if your server eventually finishes the work.
@Doug_P, your roughly 1 second “No response from app” with nothing in your server logs doesn’t look like a timeout on the stufrace. A timeout would sit right around the 5000ms mark. When it fails that fast with zero trace on your side, the request usually didn’t complete the connection into your app at all. We never receive a status code back, so it shows as “No response from app”, and your app never logs it because the request never reached it.
I’ll send you a DM with a request for some specific information I can use to check our logs 
Hey @Doug_P 
following up here after digging into the two examples you sent over.
Good news first: no events were lost. Both webhooks were created and sent on our side, the first attempt failed, and the automatic retry (~1 second later) succeeded with a 200.
The retry reuses the same X-Shopify-Webhook-Id, so the successful re-delivery carried the identical ID as the failed attempt. That’s why the docs recommend using that header to dedupe: a webhook can look like it “never arrived” while a 200 for the same ID lands a second later. Verify webhook deliveries
The two cases were two flavours of the same underlying thing. Shopify uses a one-second connection timeout and a separate five-second timeout for the whole request (both documented at the link above):
- The ~1 second case is the connection timeout. We couldn’t open the TCP connection to your host within that ~1s window, so the request never reached your app. This is why there’s nothing in your server logs for it. It’s different from the 5s response timeout.
- The ~6 second case (closer to what @parker described) is the request timeout. There the connection did open, but the app didn’t return response headers before the 5s deadline, so it was recorded as a failure even though the work may have finished.
This isn’t a Shopify-side change or a webhook bug. Both examples failed at the connection layer (one before the socket opened, one before headers came back), then succeeded immediately on retry. Shopify retries 8 times over 4 hours with exponential backoff, which is why this kind of intermittent first-attempt failure almost never surfaces to a merchant but still shows up in your logs.
The most reliable way to drive these down is to make sure your endpoint accepts connections fast and returns a 200 quickly, then process the work out of band. That way, you never get near the 1s connect / 5s response deadlines. The doc I linked above references this pattern as well.
Your instinct to split webhooks into their own service is a solid move too as it isolates them from the main app’s load.
I’ll follow up via DM with the more specific endpoint details I pulled, since that gets into your system specifics. I’m happy to dig in further if you have any other questions as well
Thanks for the explanation, but what you’re saying only makes sense when the request was actually received.
1-Second Timeout: Ok, I get this, you couldn’t open the connection - yet the app is attributed with an “ERROR”? That feels wrong as this is on the Shopify side, not the app side.
6-Second Timeout: Yes, correct, this is the flow this is supposed to take:
- Shopify opens the connection to the app (with 1 second timeout to do so).
- App receives the connection and begins to process the request from the webhook.
- App responds to the request from Shopify with a 200 (“webhook received ok”).
- App records length of time and request destination (among other things) it took to respond.
- App queue’s the payload or “handles” the webhook.
However, I’m detailing out that the 6-second timeout NEVER reached stage 2. Therefore, my server has no knowledge of Shopify sending the request, yet Shopify indicates there was no response from the app - again, erroneously “apps fault”. The error is again on the Shopify side because the request was never actually received by the app’s servers.
Keep in mind, there are a fairly low number of these that happen in the midst of thousands of successful request/response handshakes - but they do happen. I’m trying to figure out why Shopify thinks these were successful sends when clearly the receiving side knows nothing of them.
Oh, by the way, I do queue requests, but I respond with a 200 when I actually receive the request. Most responses are made in < 50ms.
@Doug_P just closing the loop on this after our discussion via DM as I wanted to summarize the broader takeaway of our chat publicly
The main clarification is that No response from app is a delivery outcome for that webhook attempt. It means Shopify didn’t receive a successful HTTP response from the configured endpoint before the delivery timeout. It isn’t meant as a blame label against your application logic, though I can see how it reads that way in the dashboard.
I also want to acknowledge the scale point you raised. From the examples we looked at, these appear to be a very small percentage of total webhook deliveries, and retries are recovering the cases I checked. That said, I hear you on not wanting persistent delivery errors in the first place, even if they’re rare.
A useful distinction here is that the app handler’s processing time and Shopify’s delivery timing can both be true while measuring different parts of the path. Shopify is measuring whether the configured endpoint returned response headers in time. Your app logs may be measuring when the backend handler received, queued, or processed the webhook. If there’s a hosting frontend, proxy, load balancer, rewrite, cold start, or runtime capacity layer between those two points, the two views can diverge.
For anyone debugging a similar pattern, I’d suggest correlating by X-Shopify-Webhook-Id, X-Shopify-Event-Id, delivery attempt timestamp, and the hosting or edge logs in front of the app, not only the app handler logs. The key questions are: did the request reach the public endpoint, did it reach the webhook handler, when were response headers written, and what status was returned to Shopify?
Shopify’s webhook docs call out a one-second connection timeout and a five-second timeout for the whole request. In practice the connection budget plus the request window works out to roughly six seconds end-to-end, so a delivery timeout measured at around six seconds is expected rather than a contradiction. The docs also recommend returning 200 OK quickly before doing longer processing asynchronously: Verify webhook deliveries
Hope this helps!