I’m having occasional issues with the /v2/create-phone-call endpoint. It usually works fine and very quickly. But I’ve had a couple times recently where it times out and the call is not started.
We have our timeout set to 30 seconds. Just this morning at 2026-03-12 16:30:35.115893+00, we sent a request to the create phone call endpoint. We waited for 30 seconds, got no response, and timed out.
I’ve looked on our end and haven’t seen anything wrong. I’ve double checked the payload we sent – the To number was a valid number, and the From number was a valid Retell number assigned to an outbound agent. Before and after the incident, we have successfully made calls from this number.
What else could have gone wrong here? Is anyone at Retell able to look at logs and see what happened?
Thank you for reaching out to Retell AI Support. We’ve received your ticket and our team will respond within 8 hours.
Hi Retell,
Hi there,
Thanks for reaching out!
For how-to and product usage questions, please post your question in the Retell Community Forum, which is our official support channel. Our team actively monitors the forum and responds within 8 hours (SLA).
Submit your question here: Retell Forum Support
You can also explore these additional support options:
We’re excited to help you get up and running.
Best,
Retell Support Team
Best,
Evy AI
AI Support Agent @ Retell AI
Hello,
Please share the call ID(s) where you experienced this issue if they are available, otherwise, you can provide your workspace ID (from here: https://dashboard.retellai.com/settings/workspace), so we can investigate this further.
Regards,
Retell Support Team
Workspace ID is org_ymYpvvwy9chMIVv0. I don’t have call IDs, because we aborted before the call was created because of the timeout.
Hello,
We’ve confirmed the cause of your 16:30:35 UTC timeout. Our API experienced a brief but significant latency spike specifically on the create-phone-call endpoint during 16:30-16:32 UTC that day, where a significant number of requests platform-wide were taking over 30 seconds to respond. Your request was caught in this window and exceeded your 30-second client timeout before a response could be returned, which is why no call was initiated.
The platform had fully recovered by 16:42 UTC, when your next request completed in 62ms. This was an isolated occurrence, not an issue with your payload, phone number, or agent config.
Please let us know if you encounter the same issue going forward.
Regards,
Retell Support
As I’ve started looking into more errors in our system, I’m realizing that this issue is happening more than I thought it was…
Once I saw it a few more times, I added more logs into our system to more easily see when start call requests to Retell are timing out. Just this morning alone, we’ve had 40 start call requests that hung for 30 seconds, then we timed out and moved on. I’ve included information about these call requests (from number, to number, and timestamp of when we sent the request to Retell).
This is the workspace ID for all these calls: org_QUBjSYml3RbF40Fs
These calls were all within the space of an hour. I’m concerned by the amount of calls that we must be trying to make, but haven’t been able to.
| From Number |
To Number |
Request Start Timestamp |
| +17252425305 |
+14796404594 |
2026-03-23T15:14:47Z |
| +17253021873 |
+12126245856 |
2026-03-23T15:18:42Z |
| +17253021873 |
+19182241134 |
2026-03-23T15:38:16Z |
| +17252425305 |
+12486182141 |
2026-03-23T15:38:31Z |
| +17253021873 |
+19498915780 |
2026-03-23T15:39:09Z |
| +17253021873 |
+19182241134 |
2026-03-23T15:39:15Z |
| +17252425305 |
+19184088431 |
2026-03-23T15:39:27Z |
| +17252425305 |
+12486182141 |
2026-03-23T15:39:31Z |
| +17253021873 |
+15736901950 |
2026-03-23T15:40:04Z |
| +17253021873 |
+19498915780 |
2026-03-23T15:40:10Z |
| +17252425305 |
+14044911965 |
2026-03-23T15:40:25Z |
| +17252425305 |
+19184088431 |
2026-03-23T15:40:28Z |
| +17253021873 |
+12137063003 |
2026-03-23T15:40:58Z |
| +17253021873 |
+15736901950 |
2026-03-23T15:41:04Z |
| +17252425305 |
+16504524134 |
2026-03-23T15:41:22Z |
| +17252425305 |
+14044911965 |
2026-03-23T15:41:25Z |
| +17253021873 |
+19182241134 |
2026-03-23T15:41:46Z |
| +17253021873 |
+14347131141 |
2026-03-23T15:41:52Z |
| +17253021873 |
+12137063003 |
2026-03-23T15:41:58Z |
| +17252425305 |
+12486182141 |
2026-03-23T15:42:01Z |
| +17252425305 |
+17143495052 |
2026-03-23T15:54:25Z |
| +17253021873 |
+13303430388 |
2026-03-23T15:54:27Z |
| +17252425305 |
+13479796261 |
2026-03-23T15:55:18Z |
| +17253021873 |
+16023304676 |
2026-03-23T15:55:22Z |
| +17252425305 |
+17143495052 |
2026-03-23T15:55:24Z |
| +17253021873 |
+13303430388 |
2026-03-23T15:55:27Z |
| +17252425305 |
+5511945389983 |
2026-03-23T15:55:41Z |
| +17253021873 |
+5542991548498 |
2026-03-23T15:56:16Z |
| +17252425305 |
+14802835761 |
2026-03-23T15:56:19Z |
| +17252425305 |
+13479796261 |
2026-03-23T15:56:19Z |
| +17253021873 |
+16023304676 |
2026-03-23T15:56:22Z |
| +17253021873 |
+16082195933 |
2026-03-23T15:57:10Z |
| +17252425305 |
+17063389128 |
2026-03-23T15:57:16Z |
| +17253021873 |
+5542991548498 |
2026-03-23T15:57:16Z |
| +17252425305 |
+14802835761 |
2026-03-23T15:57:19Z |
| +17252425305 |
+17143495052 |
2026-03-23T15:57:55Z |
| +17253021873 |
+13303430388 |
2026-03-23T15:57:58Z |
| +17253021873 |
+16082195933 |
2026-03-23T15:58:10Z |
| +17252425305 |
+447772985560 |
2026-03-23T15:58:19Z |
| +17253021873 |
+16034792863 |
2026-03-23T15:58:52Z |
Hello,
We’ve confirmed that during the two windows you flagged (roughly 15:38–15:42 UTC and 15:54–15:58 UTC today), your create-phone-call requests were received by our servers but experienced significant processing delays. The calls were ultimately created on our side after the delays cleared, but because your 30-second client timeout had already elapsed, your system never received the 201 response and treated them as failures.
We also noticed that your retry logic is re-sending requests for the same phone numbers after each timeout, which compounds the backlog when these stalls occur, that is the original server-side request is still running when the retry arrives.
We recommend:
-
Consider checking whether a call was already created before retrying (e.g., via the List Calls API filtered by the to-number)
-
If possible, add a short backoff between retries to avoid amplifying any temporary delays.
As for the root cause of these stalls, we will be forwarding this to the engineering team and will get back to you shortly.
Regards,
Retell Support Team
Hi there,
I took a look at a few calls, looks like the latency are low in our end, most of them are within a few hundreds of milliseconds in our end.
Could you add some metrics in your end to see the latency breakdown?
Regards,
Retell Support Team
We’ve got start/end timestamps wrapped directly around the request we’re making to https://api.retellai.com/v2/create-phone-call. I queried my logs again, and in the last hour we’ve had 68 failures (from 2026-03-25 15:41:35.609863948 +0000 UTC to 2026-03-25 15:47:30.680285392 +0000 UTC, and then from 2026-03-25 16:01:55.400797731 +0000 UTC to 2026-03-25 16:14:51.51078087 +0000 UTC). Most of them went about 29 seconds before we canceled.
I hear your suggestion for checking whether a call was already created before retrying. I did a random sample of some of the calls I had reported before to see when/if the call went through. I searched for calls made to those number in the Call History dashboard in Retell. My findings are in the table below.
My concern is that some of the calls I searched took up to 4 minutes to start. Even if we implement this check and a backoff of a few minutes, there’s still a chance that the call hasn’t started yet, and we end up sending a duplicate request anyway on the retry.
| To Number |
Time Sent |
Time First Call Started |
Difference |
| +19498915780 |
2026-03-23T15:39:09Z |
2026-03-23 09:42:37 MDT |
~3 minutes |
| +12486182141 |
2026-03-23T15:39:31Z |
Never |
|
| +15736901950 |
2026-03-23T15:40:04Z |
2026-03-23 09:42:36 MDT |
~2.5 minutes |
| +12137063003 |
2026-03-23T15:40:58Z |
2026-03-23 09:44:45 MDT |
~4 minutes |
| +17143495052 |
2026-03-23T15:54:25Z |
Never |
|
| +13303430388 |
2026-03-23T15:54:27Z |
2026-03-23 09:58:39 MDT |
~ 4 minutes |
| +13479796261 |
2026-03-23T15:56:19Z |
2026-03-23 09:58:27 MDT |
~ 2 minutes |
| +13303430388 |
2026-03-23T15:57:58Z |
2026-03-23 09:58:39 MDT |
~ 1 minute |
| +16034792863 |
2026-03-23T15:58:52Z |
2026-03-23 10:00:10 MDT |
~ 1 minute |
Attached is a timeline of our logs for the timeframe mentioned previously. Blue indicates successful outbound calls, and yellow indicates timeouts.
One thing we’ve observed is that these timeouts tend to happen in bursts rather than randomly. When they start occurring, it appears that most or all requests during that window are impacted, which makes it feel like a temporary system-wide issue rather than isolated request failures.
Hi there,
I feel that this might be some network latency/congestion in your side, because even if a request can not be started, we will still log out a message but I am not seeing any logs for the ones you mentioned that were never started.
Also, for the ones with high latency, I can see that in our side the latency is a few hundreds of milliseconds to seconds, definitely not a few minutes.
So overall, it’s more likely that the requests took really long time to reach Retell (or could not reach at all in some cases).
Regards,
Retell Support Team
