Hi all, I have been having trouble getting my VAPI assistants to consistently say the end call message. I've tried adding the end call as the follwing, and it seems its always very inconsistent in actually saying the message. - within my prompt, Ive included an end call message in the #call closing section - to the "endCallMessage" field on the assistant - as a message on the end_call_tool, ive tried with request complete with 'End the call after message is spoken' In the call Id below, i DO see a voice log with my end call message near the very end of the call, but it seems the 'Vapi voice WebSocket disconnected'. it looks like the voice socket gets disconnect before it can actually say the message? Call Id: 019b390b-3420-7776-bc9d-6a25af194eef Org Id: 211c53bc-1b1f-4efb-97f2-4f2cbde0da50

Hi there, Thank you for your message. Our team is currently out of the office. We operate Monday through Friday, from 9:00 AM to 8:00 PM Pacific Standard Time (PST). We’ll get back to you as soon as possible during our normal business hours. If your message is urgent, please mark it accordingly or include “URGENT” in the subject line, and we’ll do our best to respond promptly. Warm regards, Vapi Customer Support Team

To help ensure your end call message is played, set the

endCallMessage

field directly in your assistant configuration and make sure the call flow allows time for the message to finish before disconnecting. For example:

json
{
  "endCallMessage": "Thank you for calling. Goodbye!"
}

After updating, monitor your call logs in the dashboard to verify the message is spoken before the WebSocket disconnects. This approach is recommended in the [API Reference documentation](https://docs.vapi.ai/api-reference/assistants/list?explorer=true). Source: - [API Reference documentation](https://docs.vapi.ai/api-reference/assistants/list?explorer=true)

This looks like a timing issue where the call ends before TTS finishes playing. Even though the end message appears in the logs, the voice WebSocket disconnects too early. Best practice is to use one closing method (preferably end_call_tool) and ensure “end call after message is spoken” is enabled, with no other logic ending the call. Quick check: do you have any timeouts, webhooks, or client-side logic that might be closing the call immediately after the tool fires? @randomreaper

No client side logic, and just default timeouts. But I did have the end of call report webhook enabled

Hi randomreaper, Thanks — I reviewed the docs on Call Ended Reasons and Debugging Voice Agents and the related threads. Short answer and concrete next steps: Likely cause - Race between the end-call action and TTS finishing: the end-call tool fired (or connection closed) before the last TTS audio finished, so the voice websocket disconnected early. Docs: https://docs.vapi.ai/calls/call-ended-reason Quick checks to run now 1. Confirm no client-side code, transport timeout, or webhook actively closes the call immediately after tool fires (you said none, but re-check any infrastructure that receives the end-of-call webhook). 2. In dashboard Observe > Call Logs for call 019b390b-3420-7776-bc9d-6a25af194eef: check timestamps for: - assistant spoken messages (TTS start/end) - tool call event (endCall) - websocket close / provider disconnect That will show whether websocket closed before TTS end (see Debugging guide: https://docs.vapi.ai/debugging). 3. Ensure only one closing mechanism is used. Remove simultaneous triggers (system prompt asking to hang up + endCall tool) so the assistant only calls endCall once. 4. Use the end-call tool with a request-complete message and enable “End the call after message is spoken” (that is the supported place to guarantee hangup after TTS finishes). If you need the assistant to speak a custom closing phrase, set assistant.endCallMessage too (docs: https://docs.vapi.ai/api-reference/assistants/list?explorer=true). 5. Lower model temperature and ensure the model does not call endCall in the same response chunk that also produces spoken text (avoid LLM returning tool call + speak concurrently). If the problem persists (after steps above) - Capture one failing call’s raw logs and the Observe timing (timestamps) for the events above and share those timestamps here so I can confirm whether the disconnect came from Vapi closing the transport or from the provider/webhook/your infra.