BTW, we saw a spike on Twilio's 31901 error code. From what we could observe, the call rings, we create the call using POST /Call API but the assistant never connects

BTW, we don't manage the websocket connection to transmit media stream. This is on Vapi

When we create the call, Vapi provide the transport details, so we send the twiml with Vapi websocket URL

@Vapi we're seeing errors increasing in Twilio right now.

And we saw some 502 in the middle of the failures....

Some timeouts as well 😡

@Vapi Incident help here!! A lot of calls being dropped.....

And for some reason, even with calls being dropped we receive a notification indicating that concurrency limit has been reached

Twilio error rate: increasing a lot https://cdn.discordapp.com/attachments/1491872648261668916/1492200150431694858/image.png?ex=69da772f&is=69d925af&hm=1b4d560cbf27cc0fbadfba85b877a18b411e47eaf8944cb2b2629e7a662385ab&

@Vapi Support Bot @Vapi @Vapi Incident

Also @Leo though this is surely a vapi issue, perhaps they made some change that is choking on something with our setups. do you want to chat briefly and see if we're both using some setting that VAPI doesn't like anymore?

@User a few data points on our end that might help pattern-match: - Our failures started 2026-04-08 ~16:15 UTC and the symptom is identical: Twilio 31901, VAPI shows

customer-did-not-answer

with 0 messages, no recording, no transcript, Start Time = N/A, end-of-call-report webhook arrives ~6 min later. - The stream URL in the TwiML VAPI hands back to us points at

phone-call-websocket.aws-us-west-2-backend-production-**weekly2**.vapi.ai/{callId}/transport

. Can you check yours? I'm curious whether you're on weekly2 too, or on a different cluster instance. If you're on weekly2, that's a strong pointer at a specific bad cluster. - We were moved from weekly1 → weekly2 on the morning of Apr 7, ~24–36h before our failures started. Your ramp (Apr 5: 18 → Apr 7: 179) would fit a similar migration happening ~1–2 days earlier for you. Worth asking VAPI support when your numbers were last moved. - Last night (Fri ~midnight UTC-4) I tested on both Daily and weekly2 in rapid succession from two phones — everything worked on both. But I can't tell if weekly2 was actually fixed or if it's just low weekend load masking the bug. Very much hoping it holds for Monday. - Your "concurrency limit reached" notifications showing up even on dropped calls is a big deal — it's consistent with what I've been seeing, where failures are much worse when calls are close together. Smells like a per-cluster resource pool that's either leaking or under-provisioned on weekly2. Happy to DM and compare notes on setup — if we can rule in/out anything common between our configs (size of prompt, keyterm list length, transient vs imported assistants, etc.) that'd help VAPI narrow it down.

@User @Vapi Incident @Vapi Support Bot — consolidating what @Leo and I have between us, this looks like a specific-cluster issue: - Two independent customers, different orgs, same symptom: Twilio 31901, VAPI call shows

customer-did-not-answer

with

cost: 0

, 0 messages, no logs/transcript/recording, Start Time = N/A. - **Cluster**: our failing stream URL host is

phone-call-websocket.aws-us-west-2-backend-production-weekly2.vapi.ai

. Leo is checking his. - **Ramp**: Leo saw 18 → 81 → 179 → 138 failures/day Apr 5–8. Ours started Apr 8 ~16:15 UTC. We were moved weekly1 → weekly2 on Apr 7 morning, ~36h before failures began. - **Concurrency signal**: Leo is seeing "concurrency limit reached" notifications on dropped calls. We see failures cluster tightly under concurrent load. Points at a per-cluster resource pool, not a per-customer quota. - **Architecture**: both of us POST

/call

with transient config and return VAPI's TwiML to Twilio — the WS handshake is Twilio ↔ your edge, nothing customer-side is in the audio path. - **Misclassification**: these calls are being bucketed as

customer-did-not-answer

when the actual failure is the WS upgrade never getting a response. That's probably why it hasn't tripped your internal alerts — they're sitting in a "customer's fault" bucket. Failing call:

019d7875-daac-7000-a141-394278ca6bbd

(2026-04-10 17:34:42 UTC). Composer confirmed

cost: 0

, no logs, no transcript, no recording — but checking whether Twilio's WS upgrade reached your edge needs SRE. **What we need**: someone with infra-log access to check weekly2 handshake success rates Apr 5–11, and tell us whether it's (a) a known issue, (b) fixed overnight Apr 10→11 (which would explain weekend tests passing), or (c) expected to come back Monday. I have a customer demo Monday on this infra. Can share more call IDs if useful.

7 calls dropped in the past 5 minutes. Nothing from Vapi yet 😮‍💨 ----- Update 10 calls dropped in the past 6 minutes...

Another one here: 019d8c33-4987-799e-97bf-af6bad8b41a7 (happened 30 min ago)

Just updating here, we still seeing errors. Last 24 hours ~220 calls dropped. As we can see in the graph, the errors started ~1 PM, reaching a peak at 5 PM (UTC). Considering the patterns of the last week, I believe we will see more errors today. @kyle do you have any clue? https://cdn.discordapp.com/attachments/1491872648261668916/1493674091511812116/image.png?ex=69dfd3e6&is=69de8266&hm=1692c9c0b21de37065e54e1dc3e3b8c2cd8a6426b231cd9c5a946d274bf7c40f&

Hey @Allen are you still facing the issues? I'm thinking about a race condition in Vapi that can be fixed on my end instead of waiting Vapi. The fix consists in adding a delay to wait Vapi to have the call created... I need to test. Just would like to share with you this insight

Hey @Vapi any updates here? We're still having issues