Call service disruption

What to do

• Check whether you use Retell AI Web Call, Phone Call. Check your stack

  Paste a package.json, lockfile, Terraform or a list of domains at down.guide/stack to see every provider you depend on.

• Confirm your retries, queues and scheduled jobs caught up after the 0m it lasted.

  Anything that failed between 2026-09-17 01:35 UTC and 2026-09-17 01:35 UTC may need a replay.

• Subscribe to Retell AI's feed to hear about the next one first. RSS feed

  https://down.guide/feed?provider=retell works in Slack (/feed subscribe), Discord feed bots and any RSS reader.

Updates from Retell AI 3

1. investigatingSep 17, 2026, 1:15 AM UTC

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

   provider

2. resolvedSep 17, 2026, 1:35 AM UTC

   The issue has been found and resolved. About 22% of calls may have been affected and been ended early, or have no audio. A postmortem will be published by EOD 09-17.

   provider

3. postmortemSep 17, 2026, 2:30 AM UTC

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

   provider

Corrections

None so far.

Something wrong on this page? Report an error or send us a note. Every fix is listed here.