Degraded Performance, Server-Side Errors, and Perpetually Ongoing Calls

Support Help
1

I spend $10k a month on Retell, and I am this close to switching. Over the past month, the reliability and quality of the product has visibly degraded. Today, at least 5 separate calls were terminated for Retell server-side errors. Latency complaints are through the roof, especially on long conversations. Sometimes, calls remain perpetually in the ongoing state, which is the same thing for my purposes as a server side failure, except silent.

These reliability issues need to be addressed. I run expert calls that cost my clients hundred of dollars a piece. Losing one to a silent bug is not an option.

2

Hey @adam Sorry for the inconvenience. Could you please share those 5 Call IDs so we can check them and investigate the issue further?

Thank You

3 
call_a6f615bea2d88e5b233bb3dc3c6
call_bb76315058bd5a76a3757034e3e
call_f52209197bc8c5d185d960d8398
call_d8d771020862895ad454d72fd9d
call_e1f04b88eae6c98e4dd8e24ed8c
call_41ea4e3a04fd3d7d037217edd50
call_d4b0cb838b0f86e1638377ad05e
call_5a21b6115e7e1a9b61167cb6e2d

All of the above failed with error retell

4

Hey @adam I’ve escalated this to the team for further investigation. I’ll get back to you as soon as I have an update.

Thank You

5

Looking more closely at this, it seems that our degraded performance can trace directly to our migration from the create web call v2 to the create webcall v3 api. We’ve temporarily rolled web-call creation back to v2/LiveKit. Could you please:

Escalate this to your gateway/media engineering team to investigate and recommend a fix.
Confirm when v2 requests will actually stop working, and whether you can keep v2 available for our workspace until this is resolved. The notice says September 30 deprecation, but the shutdown date isn’t clear. Supporting claude slop and call IDs are below for engineering:

Additional details for engineering

Workspace: org_0bNzcdZpgMQLcWWe (adam@clairvoyantresearch.com’s) Agent: agent_4e292518c743e8e2e849b5d2bc Migration: Python SDK 5.55.0 → 6.0.0; browser SDK 2.0.7 → 3.0.1; LiveKit web calls → v3 gateway calls.

We restored production web-call creation to v2/LiveKit on September 18 (deployment completed at 17:45 UTC), keeping Python SDK 6.0.0 and browser SDK 3.0.1.

An isolated SDK 3.0.1 + LiveKit browser test ran for 26 minutes 40 seconds with zero reported packet loss and no growing receiver buffer (first/last five-minute medians: 115/76 ms). It ended when the test laptop was closed, before the planned 32 minutes. We have not yet established post-rollback results from real interviews.

We compared 640 calls from September 1–18. Holding published agent version 57 constant, the median observed gap between the agent finishing and the user’s reply during minutes 15–30 was:

Path Eligible calls Median gap
Previous LiveKit web calls 171 0.93 seconds
Gateway web calls 92 12.97 seconds
Contemporaneous phone calls 43 1.01 seconds

Each call lasted at least 30 minutes and had at least five adjacent agent→user transitions in that window. These are medians of per-call medians computed from word timestamps. The gap includes human response time and is an observational proxy, not a direct network-latency measurement. Nevertheless, 79/92 gateway calls exceeded five seconds, and the pattern persists across Chrome/Safari and calls without logged microphone failures. It was already present on v57, before our subsequent model/STT changes.

The transport cutover closely matches our deployment. The last LiveKit call started at 2026-09-14 19:32:31 UTC; the first gateway call started at 19:43:57 UTC. Same-agent, same-version examples:

  • Gateway: call_abdbf5233ec1d9dc6b14ba326f9 — started September 14, 19:43:57 UTC; middle-window median gap 18.54 seconds.
  • Gateway: call_4123485e343d693eaf288c457ef — started September 14, 19:48:24 UTC; gap 14.01 seconds.
  • LiveKit control: call_ca0d563293f57385ab270b8f955 — started September 14, 18:55:24 UTC; gap 0.93 seconds.
  • Phone control: call_c0ca7db7d5bcd14c5cd427c2427 — started September 14, 20:09:20 UTC; gap 0.73 seconds.

A current example is call_a21744a1a939606f741dc9a2133, agent v61, September 18, 09:26:22–10:30:25 UTC; gateway IP 3.42.144.207; Windows Chrome 153. Its reported e2e p50 is 2,979 ms and p95 4,501 ms, with LLM p50 1,282 ms. Yet the agent→user gaps grow toward 20 seconds late in the call. At call time 55:39.973, the agent finishes a question; the user answer begins at 56:00.020. The 20.047-second gap is also present in the stereo recording. We observed separate microphone failures early in this call, but those do not explain the later pattern or the wider cohort.

Your documented e2e metric excludes delivery from Retell to the frontend, so please investigate media timing, RTP timestamps, audio pacing, and queue/buffer growth rather than relying only on LLM/e2e metrics. We have not yet established whether the defect lies in the gateway, browser SDK, or an interaction with our client.

We can provide the per-call timing dataset and browser telemetry. Please let us know what additional WebRTC stats or reproduction details would help.

6

Hey @adam I’ve escalated this to the team. If they need any further information from you, I’ll let you know.

Thank You

7

Hello @adam we found an issue with some calls last week, and have fixed the bug causing those issues. Going forward you should see no more calls that do not get ended. Additionally, we are looking into reports of increased latency, will update when we have fixed that.

Thank You