This has happened a few times throughout the day. Call logs from some customers did not record in dashboard. These conversations with this error are not recorded and we have no way of getting transcript or recording of the full conversations. This example below is from one phone number. It looks like the customer has tried to call three times but we have no records, transcript or analysis information. Call ID: d92bdf4d-f0e4-44ee-ac26-7f136c89a524 Call ID: 4e92cf0e-31ac-4bf5-bd95-5b05712d362a Call ID: 5084a91f-f3ed-49de-97b6-b57263e01a5c

Hey Beck, the following calls have been failing because of 11labs error. https://cdn.discordapp.com/attachments/1341994769148280833/1342284918574813344/Screenshot_2025-02-21_at_5.29.48_AM.png?ex=67b913bf&is=67b7c23f&hm=3bd4b7f9d7b039de3f526899d9c7aab20587f4048b4c6419ea85fdb1bfc71c14&

Could you please help me identify how this error is related to 11Labs - could you please provide more context on the screenshot you shared? This will allow me to pinpoint what is happening and move forward to troubleshooting with 11Labs if need. Just need clarity on where this is pulled from in Vapi that clarifies 11Labs error. Thanks

The calls failed due to an error occurred from 11labs during the call. They are now aware of the issue, but the dashboard problem is different. I require the Loom for the dashboard so that I can share it with the team. Meanwhile, the 11labs issue is already in discussion with them.

I don't quite understand. You mentioned the calls I shared have been failing because of 11Labs error - I want to understand how this was identified to be an 11Labs issue for these calls? Is there something in the call logs that specifies this? I am not able to share Loom video for privacy reasons.

In our logs, 11Labs reported the aforementioned error message, which I have shared with you previously. Upon receiving this information, we promptly terminated the current call, as it could not be continued further. This occurrence serves as an indicator of an 11Labs issue for these calls. You can review this information in the call logs. If you wish, I can export the logs for your convenience and share them with you.

Hi @Shubham Bajaj as you mentioned this is an 11Labs issue that has been fixed - I will leave this query for now. We have not experienced this issue in the last two days. thanks!

Call ID: a13ce0e3-34fc-48dc-9b68-f931e9e1b97c "endedReason": "customer-ended-call" Call ID: 976a8469-e7ff-4bed-be0b-3be718357e83 "endedReason": "customer-ended-call", @Beck sorry for the delay, can you check the call ID again these are not related to 11labs issue in discussion.

Hi @Shubham Bajaj , I just checked both calls and they are the correct ones - showing the same error as per the first calls of this Ticket. Both calls show "[ERROR] end-of-call-report Server URL Error: Request failed with status code 500" in logs

@firefly_0206 checking the call logs.

Hi @Shubham Bajaj , thank you for the prompt response. We'll check on this with the team. And to help us understand the vapi-fault - how many calls can an Assistant handle at one time without fault?

This is something which happens rarely on side effects of switching b/w different clusters.

@Shubham Bajaj I have got to the bottom of what's going on in the server. An exception is being thrown by the API because an expected property that is available in the vast majority of end of call reports is the structured analysis data The exception thrown is

structuredData is missing in analysis

And this is in reference to the following structure in the end of call report; { message: { analysis: { structuredData: { } } } } Using the call ID 10067a06-cc34-4179-9308-9fd870c4518b. Are you able to tell me if the call analysis model is reliably consulted before the end of call report is dispatched?

@Doxy we wait for all call analysis node before gnerating and sending the end of call report.

@Shubham Bajaj understood, any idea why the structured data is missing from the payload? Is there anything we can do on our end?

For the first call ID shared.

"type": "end-of-call-report",
  }
`

@Shubham Bajaj Understood. If you wouldn't mind, can you please remove these messages now that they are seen. The structured data was missing when this payload was sent to the server * Does this mean there's a race condition where the end of call report is dispatched before the request to populate the structured data is complete? * If we increase the timeout on the structured data call, will this cause the end-of-call report to be delayed? * Is there a way we can cause the end-of-call report to wait indefinitely until the structured data has been resolved? The nulls are expected we can account for this Can you please help me understand the timeline of events here.

Also having this issue with end of call reports not being received. Is there any fix?

NO there is no race condition instead it takes time to process so increasing the time will fix it for you. Try increasing the timeout it will work.

@Shubham Bajaj ok understood. If the application fails to resolve the structured data in the timeout period, will it be attempted a second time?

@Doxy It will be attempted only once. The maximum timeout is 60 seconds. Rest assured, if set to 60, you will always get the structured data without a doubt.

Ok thanks

@Doxy if you have more doubts let me know, I can spin up an document for you....