https://vapi.ai/ logo
Join Discord
Powered by
Calls starting with "Goodbye" and end call
# support
m
Yesterday, we have a spate of calls immediately starting with a "Goodbye" and hanging up. When I first raised these issues Vapi support recommended I add a 
firstMessage
to each assistant, despite using "model-generated first message mode". That's already been done, but we are still experiencing the same issue Our org id: 83c39998-3bd6-4e1d-b4df-4b00f91cf4ce Call log records * https://dashboard.vapi.ai/calls/019d0108-c5f2-7000-8d7e-2bddfff9ee1f * https://dashboard.vapi.ai/calls/019d0195-e566-755a-a999-b154bccbd656 * https://dashboard.vapi.ai/calls/019d01dc-c122-766f-9311-457d80fdbc3a * https://dashboard.vapi.ai/calls/019d01dd-4bfb-7000-87a8-57aaa2a3d46d I took a look at the jsonl log files for one of the calls, and one thing stood out for me, the "Azure OpenAI HTTP response" (the only one in the log file), the response body was 
content: ""
(an empty string). see attached screenshot. What I was expecting is to see a response from the LLM model, instead of the empty string. Looking at the Vapi status, I see there's degraded performance for the Provider > OpenAI models, too. Is this a likely culprit for the calls being terminated at the start? And how do we catch, or work around this issue? https://cdn.discordapp.com/attachments/1484155668221923429/1484155668448673825/Screenshot_2026-03-18_at_17.51.42.png?ex=69bd332d&is=69bbe1ad&hm=1d4ba8cc9343f8ded137cbf7e3ad4aa170b3212db80a4bdbab613a0d97128153& https://cdn.discordapp.com/attachments/1484155668221923429/1484155668943470653/Screenshot_2026-03-19_at_11.43.07.png?ex=69bd332d&is=69bbe1ad&hm=cc14957044323d3b04e4da38e8d01b548b515bfc6a71c5e70cdeb40be1cd2847&
v
Based on the documentation, calls can end immediately if the LLM (like Azure OpenAI) returns an empty response, often due to provider-side issues or degraded service. To confirm this is the cause, check the 
endedReason
field in your call logs for codes such as 
call.in-progress.error-providerfault-*
or 
pipeline-no-available-llm-model
.
Copy code
text
// Example: Check call log details in the Vapi dashboard
1. Go to your call in https://dashboard.vapi.ai/calls
2. Look for the "Ended Reason" field in the call details
This will help you verify if the provider issue is responsible for the call termination and guide your next troubleshooting steps. For persistent issues, monitor provider status and consider retry logic in your workflow. Reference: [Vapi Call Ended Reasons Documentation](https://docs.vapi.ai/calls/call-ended-reason) Source: - [Vapi Call Ended Reasons Documentation](https://docs.vapi.ai/calls/call-ended-reason)
m
@User I see the 
endedReason":"assistant-ended-call"
s
Hi, thanks for the call IDs. We're investigating them and will soon get back to you.
Hi
Azure OpenAI was returning malformed responses with 0 completion tokens, causing the LLM to immediately fire an endCall() tool call instead of generating a response. The "Goodbye" comes from your endCall tool's request-start message, not the LLM itself. This is why firstMessage didn't help — it plays correctly, but the failure happens on the first LLM response turn after that. 6 out of 72 calls on March 18 were affected (8.3%), correlating with the Azure degradation you flagged on the status page. Recommended mitigations: Add a fallback LLM — configure a secondary provider (e.g. standard OpenAI or Anthropic) so malformed Azure responses trigger a retry automatically Simplify your endCall instructions — your system prompt has extensive TERMINAL_CLOSE/endCall logic (~10K tokens) that may make the LLM more likely to call endCall when Azure is under stress. Making those instructions less prominent should reduce false triggers Monitor the Vapi status page for Azure degradation windows — these events are provider-side and we have limited control over them Let me know if you'd like help configuring the fallback LLM!
Let me know if you'd like help configuring the fallback LLM
PreviousNext
Powered by