Retell AI Status Page

Sep 17, 2026 · resolved Sep 17

**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.

Sep 5, 2026 · resolved Sep 6

### 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\) * 10AM: A customer's custom LLM calls begin dropping before initialization completes. * Afternoon: The customer scales up traffic; the number of stalled initializations grows. * ~16:00: Nearly all containers are blocked on dequeue slots. Autoscaling does not trigger. Call placement is broadly impacted. * After 16:00: Mitigation begins: manual scale-out of containers and clearing of stuck concurrency for the affected customer. Service recovers. ### Prevention 1. \(COMPLETED\): Fix the race condition in custom LLM call initialization 2. \(IN PROGRESS\): Add monitoring and alerting on call scheduling queues to detect stuck states 3. \(IN PROGRESS\): Decouple the scheduling queue from call initialization so a slow or failed init cannot block dequeue 4. \(IN PROGRESS\): Add call scheduling queue pressure as an input to our autoscaling policies ### 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.

Aug 7, 2026 · resolved Aug 7

This incident has been resolved.

Jul 29, 2026 · resolved Jul 29

This incident has been resolved.

Jul 14, 2026 · resolved Jul 14

This incident has been resolved.

Is Retell AI down right now?

No — Retell AI is up. All systems operational as of Oct 12, 7:42 AM UTC.

What is Retell AI's current status?

Retell AI: All Systems Operational. Alert24 checks Retell AI's status page continuously and can notify you the moment it changes.

How do I get alerted when Retell AI goes down?

Alert24 monitors Retell AI and 3,700+ other cloud and SaaS providers. When an outage is detected it updates your status page automatically and pages your on-call team — no manual checks. Start free at alert24.net.