Is Retell AI down?

Between 1:45 PM PDT Oct 24th and 4:50 PDT Oct 25th, a permission issue with one of openAI speech-to-speech model providers caused calls using speech-to-speech agents to fail or go silent. Access has been restored and speech-to-speech calls are working normally. Agents using the standard (cascading) setup were not affected.

We are aware of issues with some calls and are investigating.

We have found the issue and resolved it. About 10% of calls may have been affected and have no audio.

**Status: resolved.** All times are PST. ## Summary On September 16 at 5:37 PM we deployed a planned improvement to call handling. The improvement was not meant to be active yet, but the deployment turned it on, and it began to assign live calls to workers. This change unintentionally let two workers take the same call, and each worker then started it. The two starts interfered with each other, and the call failed. About 22% of calls were affected from 5:37 PM to 6:20 PM. We stopped the new workers, rolled the deployment back, and saw the issue resolve. ## Impact An affected call shows one of two signs: * The call ends as soon as it connects. The duration is zero or close to zero seconds. * The call connects. The agent does not speak. The call ends after a silence. A call that ran correctly is not affected. Its recording, its transcript, and its billing record are correct. ## Root cause We were making an improvement to our system for call handling. As part of this change, we made a new queue for calls and a new set of workers, which was meant to be inactive. Our old servers were writing to both queues as a test, which did not cause issues as the new workers were not active. A deployment replaces servers one group at a time, so when the deployment began at 5:37PM, some servers ran the old code and some ran the new code. The old servers still wrote each call to both queues, and the new workers now read the new queue. The two systems therefore handled the same call, once each, and undid each other's work. ## Timeline \(PST\) | Time | Event | | --- | --- | | 5:37 PM | We deploy the change. | | 5:40 PM | Call errors increase. | | 5:43 PM | Our call monitor reports the first failures. | | 5:47 PM | The system pages the on-call engineer. | | 6:14 PM | We stop the new call workers. Double handling drops sharply. | | 6:18 PM | We start the rollback, which removes the change itself. | | 6:20 PM | The last affected call. Call errors return to normal. | | 7:54 PM | The rollback finishes. | ## Prevention 1. \(IN PROGRESS\) **Improve rollout process checks** We will improve our process checks for large changes to ensure that future deployments roll out in the intended state, and explicitly call out deployment time checks. 2. \(IN PROGRESS\) **Let the monitor stop a deployment.** We will connect our call monitor to our deployment system. Repeated failures will then stop a deployment. ## Closing We are sorry for the disruption. A failed call is a bad experience for you, and for the person you called.

We are investigating an issue causing web and outbound calls to fail and inbound calls to experience connection delays. We will provide an update as soon as more information is available.

The issue affecting web, outbound, and inbound calls has been resolved. All calling services are operating normally.

### Summary On September 5, a rare race condition in our custom LLM call path caused call scheduling queues across our fleet to stall. Because the failure also made containers appear underutilized, autoscaling never triggered. Between roughly 10:00 and 16:00 PST the impact grew until most containers were stuck and new calls could not be placed. ### Impact * **Web calls, outbound calls, and inbound calls** were all affected. * Inbound calls were the least affected, since they hold the highest priority in our scheduling queue. * Peak impact occurred around 16:00 PST. ### Root Cause The failure required a specific sequence of events: 1. **Stalled initialization.** If a call ended before its custom LLM websocket was established, the call's initialization never completed. The scheduling queue waited indefinitely for that initialization to finish. 2. **Queue exhaustion.** Each container allows a fixed number of concurrent dequeue operations. Enough stalled initializations consumed all available slots, leaving the container unable to pick up new calls. 3. **Misleading scaling signals.** The call-end path still ran and decremented the container's concurrency counter. As a result, stuck containers reported low concurrency and low resource utilization — so no scale-out was triggered. With every container blocked and autoscaling idle, new calls had nowhere to go. This pattern is only reachable through that exact ordering, which is why it went undetected until it occurred at scale. ### Timeline \(PST\) ### Prevention ### Closing We apologize for the disruption. We are treating this as an opportunity to harden our scheduling and scaling infrastructure, and we will ship the remaining action items within a few days.

Due to issues with an upstream provider, we are seeing connection issues for a portion of inbound calls. This is not widespread.

Service should be back to normal. We are continuing to monitor to ensure stability.

This incident has been resolved.