# Create Phone Call via API timing out

**URL:** <https://community.retellai.com/t/create-phone-call-via-api-timing-out/1089>\
**Category:** Support Help\
**Tags:** bug\
**Created:** [March 12, 2026, 9:32pm UTC](https://community.retellai.com/t/create-phone-call-via-api-timing-out/1089 "2026-03-12T21:32:54Z")\
**Posts on this page:** 16\
**Page:** 1

<div class="post-metadata">

**Author:** ![blake.johnson](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/blake.johnson/32/1077_2.png) [@blake.johnson](https://community.retellai.com/u/blake.johnson)\
**Post date:** [March 12, 2026, 9:32pm UTC](https://community.retellai.com/t/create-phone-call-via-api-timing-out/1089/1 "2026-03-12T21:32:54Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![support2](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/support2/32/15_2.png) [@support2](https://community.retellai.com/u/support2)\
**Post date:** [March 12, 2026, 9:43pm UTC](https://community.retellai.com/t/create-phone-call-via-api-timing-out/1089/2 "2026-03-12T21:43:28Z")

</div>

Thank you for reaching out to Retell AI Support. We’ve received your ticket and our team will respond within 8 hours.  
 ![](https://canada1.discourse-cdn.com/flex008/uploads/retell1/original/1X/f790e262d20d980f4c847beba41a60ec3c6dbcee.png)

---

<div class="post-metadata">

**Author:** ![support2](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/support2/32/15_2.png) [@support2](https://community.retellai.com/u/support2)\
**Post date:** [March 12, 2026, 9:43pm UTC](https://community.retellai.com/t/create-phone-call-via-api-timing-out/1089/3 "2026-03-12T21:43:41Z")

</div>

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**](https://community.retellai.com/c/support-help/6)  
You can also explore these additional support options:

- Discuss with community members on Discord: [Join Discord](https://discord.com/channels/1186424376300679209)

- Hire a certified Solution Partner for hands-on help: [Submit a Request](https://tally.so/r/w8MJ8O)

We’re excited to help you get up and running.  
Best,  
Retell Support Team

Best,  
Evy AI  
AI Support Agent @ Retell AI  
 ![](https://canada1.discourse-cdn.com/flex008/uploads/retell1/original/1X/f790e262d20d980f4c847beba41a60ec3c6dbcee.png)

---

<div class="post-metadata">

**Author:** ![support2](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/support2/32/15_2.png) [@support2](https://community.retellai.com/u/support2)\
**Post date:** [March 13, 2026, 5:15am UTC](https://community.retellai.com/t/create-phone-call-via-api-timing-out/1089/4 "2026-03-13T05:15:23Z")

</div>

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](https://dashboard.retellai.com/settings/workspace)), so we can investigate this further.

Regards,  
Retell Support Team  
 ![](https://canada1.discourse-cdn.com/flex008/uploads/retell1/original/1X/f790e262d20d980f4c847beba41a60ec3c6dbcee.png)

---

<div class="post-metadata">

**Author:** ![blake.johnson](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/blake.johnson/32/1077_2.png) [@blake.johnson](https://community.retellai.com/u/blake.johnson)\
**Post date:** [March 16, 2026, 3:07pm UTC](https://community.retellai.com/t/create-phone-call-via-api-timing-out/1089/5 "2026-03-16T15:07:05Z")

</div>

Workspace ID is org\_ymYpvvwy9chMIVv0. I don’t have call IDs, because we aborted before the call was created because of the timeout.

---

<div class="post-metadata">

**Author:** ![support2](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/support2/32/15_2.png) [@support2](https://community.retellai.com/u/support2)\
**Post date:** [March 17, 2026, 3:46am UTC](https://community.retellai.com/t/create-phone-call-via-api-timing-out/1089/6 "2026-03-17T03:46:58Z")

</div>

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  
 ![](https://canada1.discourse-cdn.com/flex008/uploads/retell1/original/1X/f790e262d20d980f4c847beba41a60ec3c6dbcee.png)

---

<div class="post-metadata">

**Author:** ![blake.johnson](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/blake.johnson/32/1077_2.png) [@blake.johnson](https://community.retellai.com/u/blake.johnson)\
**Post date:** [March 23, 2026, 4:42pm UTC](https://community.retellai.com/t/create-phone-call-via-api-timing-out/1089/7 "2026-03-23T16:42:19Z")

</div>

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 |

---

<div class="post-metadata">

**Author:** ![support2](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/support2/32/15_2.png) [@support2](https://community.retellai.com/u/support2)\
**Post date:** [March 24, 2026, 2:41am UTC](https://community.retellai.com/t/create-phone-call-via-api-timing-out/1089/8 "2026-03-24T02:41:09Z")

</div>

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:

1. Consider checking whether a call was already created before retrying (e.g., via the List Calls API filtered by the to-number)

2. 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  
 ![](https://canada1.discourse-cdn.com/flex008/uploads/retell1/original/1X/f790e262d20d980f4c847beba41a60ec3c6dbcee.png)

---

<div class="post-metadata">

**Author:** ![support2](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/support2/32/15_2.png) [@support2](https://community.retellai.com/u/support2)\
**Post date:** [March 24, 2026, 5:47am UTC](https://community.retellai.com/t/create-phone-call-via-api-timing-out/1089/9 "2026-03-24T05:47:05Z")

</div>

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

![](https://canada1.discourse-cdn.com/flex008/uploads/retell1/original/1X/f790e262d20d980f4c847beba41a60ec3c6dbcee.png)

---

<div class="post-metadata">

**Author:** ![blake.johnson](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/blake.johnson/32/1077_2.png) [@blake.johnson](https://community.retellai.com/u/blake.johnson)\
**Post date:** [March 25, 2026, 4:36pm UTC](https://community.retellai.com/t/create-phone-call-via-api-timing-out/1089/10 "2026-03-25T16:36:15Z")

</div>

We’ve got start/end timestamps wrapped directly around the request we’re making to [https://api.retellai.com/v2/create-phone-call](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.

---

<div class="post-metadata">

**Author:** ![blake.johnson](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/blake.johnson/32/1077_2.png) [@blake.johnson](https://community.retellai.com/u/blake.johnson)\
**Post date:** [March 25, 2026, 8:36pm UTC](https://community.retellai.com/t/create-phone-call-via-api-timing-out/1089/11 "2026-03-25T20:36:13Z")

</div>

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 |

---

<div class="post-metadata">

**Author:** ![blake.johnson](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/blake.johnson/32/1077_2.png) [@blake.johnson](https://community.retellai.com/u/blake.johnson)\
**Post date:** [March 26, 2026, 4:48pm UTC](https://community.retellai.com/t/create-phone-call-via-api-timing-out/1089/12 "2026-03-26T16:48:18Z")

</div>

Attached is a timeline of our logs for the timeframe mentioned previously. Blue indicates successful outbound calls, and yellow indicates timeouts.

 ![image](https://canada1.discourse-cdn.com/flex008/uploads/retell1/original/2X/3/324dd2eebe5af903f115dc15a1b384deb2d9714c.png)  
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.

---

<div class="post-metadata">

**Author:** ![support2](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/support2/32/15_2.png) [@support2](https://community.retellai.com/u/support2)\
**Post date:** [March 26, 2026, 11:36pm UTC](https://community.retellai.com/t/create-phone-call-via-api-timing-out/1089/13 "2026-03-26T23:36:49Z")

</div>

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

![](https://canada1.discourse-cdn.com/flex008/uploads/retell1/original/1X/f790e262d20d980f4c847beba41a60ec3c6dbcee.png)

---

<div class="post-metadata">

**Author:** ![blake.johnson](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/blake.johnson/32/1077_2.png) [@blake.johnson](https://community.retellai.com/u/blake.johnson)\
**Post date:** [July 28, 2026, 5:31pm UTC](https://community.retellai.com/t/create-phone-call-via-api-timing-out/1089/14 "2026-07-28T17:31:24Z")

</div>

We finally narrowed down what I think the issue is, and implemented a workaround on our end that has resolved the issue for the past few months. However, it is only a workaround, and I believe there’s still a fix to be made on Retell’s end somewhere.

## Summary

Requests to `api.retellai.com` sent over a **reused, previously idle** HTTP keep-alive connection hang until our client timeout and fail with `context deadline exceeded`. The request never reaches Retell’s application layer — consistent with your logs showing all requests served very quickly, since the failing ones never arrive.

Disabling connection reuse for Retell traffic eliminated the failures completely. We use the same keep-alive pooling against many other third-party APIs from the same hosts and egress path, and none of them exhibit this behavior.

## Client setup

Go `net/http` with a standard pooled transport (`MaxIdleConnsPerHost: 10`, `IdleConnTimeout: 90s`, `ForceAttemptHTTP2: true`). Client timeouts were 10–60s depending on path; all failed the same way.

## What we observed

With `net/http/httptrace` on failing requests:

| Field | Value |
| --- | --- |
| `reused_conn` / `was_idle` | `true` |
| `idle_time` | large (tens of seconds+) |
| DNS / connect / TLS | `0s` (pooled connection) |
| write | succeeded in \<1ms |
| TTFB | never arrived — hung for full client timeout |

Fresh connections (`reused_conn = false`) never failed. Failure correlated with how long the pooled connection had been idle.

## Likely cause

The connection is torn down or black-holed somewhere on the path **without the client being notified** , leaving a half-open socket. We write into it; no response ever comes.

A graceful close (TCP FIN or HTTP/2 GOAWAY) or RST would surface in milliseconds and often allow a transparent retry. A hang lasting the _entire_ client timeout means packets are being **silently discarded** — classic signature of a stateful middlebox (LB, proxy, firewall, NAT) expiring an idle flow and dropping rather than resetting, or a backend terminated without draining.

If you serve HTTP/2, one dead connection stalls every multiplexed request on it.

These failures are invisible in application/access logs: the requests never arrive. Detection requires looking at the connection layer (LB idle timeouts, flow expiry, drain behavior), not request latency.

## Our Workaround

`DisableKeepAlives = true` for Retell only. Confirmed twice: once when first applied, and again when a new code path accidentally reintroduced pooling and the same timeouts returned on only that path until reuse was disabled again.

This adds handshake latency and connection churn on both sides. We would prefer to re-enable pooling.

## Asks

1. Check for idle-flow expiry (firewall/NAT/LB) that drops rather than resets; ensure LB idle timeout delivers a FIN/RST to the client.
2. If serving HTTP/2, confirm GOAWAY is sent/flushed on close; consider server-side PING keepalives.
3. Confirm graceful drain on deploy/scale-in.
4. Advertise your keep-alive window (`Keep-Alive: timeout=N` on HTTP/1.1, and document it) so clients can set `IdleConnTimeout` safely below it.
5. Accept `Idempotency-Key` on `POST /v2/create-phone-call` so clients can safely retry.

**Repro:** Open a keep-alive connection, idle 60–300s, then `POST /v2/create-phone-call` on that connection while capturing with `tcpdump`. We expect request bytes to leave the client, retransmit with no ACK, and no FIN/RST from the server.

---

<div class="post-metadata">

**Author:** ![Shah-Fazal](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/shah-fazal/32/2522_2.png) [@Shah-Fazal](https://community.retellai.com/u/Shah-Fazal)\
**Post date:** [July 28, 2026, 7:28pm UTC](https://community.retellai.com/t/create-phone-call-via-api-timing-out/1089/15 "2026-07-28T19:28:10Z")

</div>

Hello @blake.johnson I have escalated this to the team for further investigation. We’ll get back to you as soon as we have an update.

Thank You

---

<div class="post-metadata">

**Author:** ![Shah-Fazal](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/shah-fazal/32/2522_2.png) [@Shah-Fazal](https://community.retellai.com/u/Shah-Fazal)\
**Post date:** [July 28, 2026, 8:17pm UTC](https://community.retellai.com/t/create-phone-call-via-api-timing-out/1089/16 "2026-07-28T20:17:17Z")

</div>

Hey @blake.johnson

Thanks for the clean write-up — the trace matches a keep-alive race between your pool and our edge. Our server socket keep-alive is 60s, and your `IdleConnTimeout` is 90s, so your pool reuses a socket after we (or the ALB in front of us) have already closed it. The write lands on a dead HTTP/2 stream and no response frame comes back, so it hangs until your client deadline. That’s why disabling reuse fixes it, and why other APIs with more generous server keep-alives don’t reproduce the signature from the same host.

To safely re-enable pooling against `api.retellai.com`:

- `IdleConnTimeout`: **≤ 50s** (strictly under our 60s server keep-alive and under the ALB idle floor).
- `ResponseHeaderTimeout`: **~30s** so a half-open reused socket fails fast instead of stalling to your outer deadline.
- Keep `ForceAttemptHTTP2: true`, but consider dropping `MaxIdleConnsPerHost` to 4–6 for this host — H2 multiplexes, so you don’t need 10 warm sockets.
- For idempotent paths, add an app-level retry on `context deadline exceeded`. For `POST /v2/create-phone-call`, retry only after a reconcile-by-metadata lookup so you don’t spawn duplicate calls (endpoint is not idempotent server-side).

Separately, ECS task drain during our deploys can also close in-flight pooled sockets without a clean HTTP/2 GOAWAY reaching your client — the retry rule above covers that class too.

Thank You