Your server rejected

tool-calls

webhook. Error: socket hang up - but the server GOT the api request and we responded back in 6seconds...so why did this happen multiple times?

Hi, thanks for reaching out! The "socket hang up" error means Vapi's connection to your server was closed before the response was fully received on our end, even if your server processed the request successfully on its side. A 6-second response time is within limits, so this is almost certainly a connection-level issue rather than a timeout. A few things worth checking: if you're running behind a proxy, load balancer, or a serverless platform (Vercel, Lambda, Cloudflare Workers, etc.), those sometimes close outbound connections before the response is fully flushed back to the caller. Also worth confirming your server sends a complete HTTP response (status + headers + body) before closing the socket, not just firing off the processing async. Could you share a call ID where this happened? That'll help us confirm the exact point of failure on our end.

019ebb74-76bf-7002-8c28-b3015b123651

Hi, I looked into call

019ebb74-76bf-7002-8c28-b3015b123651

and confirmed the exact point of failure in our logs. Vapi sent the tool-call to your

ARTDENT-SEARCHAPPOINTMENT

webhook at 10:51:27 and received a socket hang up at 10:51:32, meaning the TCP connection closed before the HTTP response body reached us. Since you're on n8n, the most likely cause is that the webhook workflow finishes executing and closes the HTTP connection before the response is fully flushed to our side. In n8n this usually happens when there's no explicit "Respond to Webhook" node, or the response node is at the end of a long execution chain. The fix is to make sure your n8n workflow responds to the webhook immediately at the start (with the result, using a "Respond to Webhook" node), and that it isn't closing the connection prematurely. If you're already using a "Respond to Webhook" node, check that nothing in the chain before it is causing a 5-second delay, our logs show the hang up at exactly the 5-second mark, which can sometimes indicate a default execution timeout on the n8n side.

we had set tool timeout to 20 sec, so this must not be the issue and it happens in mutliple calls

Hi, I've looked at the pattern across multiple calls and the issue is clearer now. Every socket hang up occurs at consistently ~5 seconds after Vapi sends the request, well before our 20-second timeout. This is not a Vapi configuration issue. The tools that fail (ARTDENT-SEARCHAPPOINTMENT, ARTDENT-STOREAPPOINTMENT) are consistently slower, while your faster tools (FREE-APPOINTMENTS-SLOTS, vapi-precall-patient-info) complete without issue. This pattern points to an n8n cloud execution time limit, n8n cloud plans impose a per-workflow execution cap (as low as 5 seconds on lower-tier plans), and when that limit is hit, n8n drops the HTTP connection. From Vapi's side that looks like a socket hang up even if the workflow eventually completes on n8n's end. The fix would be on the n8n side: either optimize the affected workflows to respond in under 5 seconds, or check whether your n8n cloud plan supports longer execution times and upgrade if needed.