Hey there! The Axios Error: error code: ECONNABORTED, error message: timeout of 12000ms exceeded error actually tells us a lot about exactly what is going wrong under the hood.
This specific error isn’t a Retell server crash—it is Axios (a JavaScript HTTP client) aborting its own request because the server it was calling didn’t respond within a configured 12-second (12000ms) window. Because Retell’s native custom function timeout defaults to 2 minutes, this clean 12-second cutoff is almost certainly hardcoded inside your own backend code or endpoint.
What is likely happening is that your endpoint handles two downstream tasks when Retell hits it: it passes the info to an email service and sends it to a separate software tool. If either of those external APIs experiences a sudden slowdown (like rate limits, a cold start, or a provider hiccup) and takes longer than 12 seconds to finish, Axios kills the execution, causing the function call to fail. Retell then naturally attempts up to 2 retries on a failed function, which stacks up the silence and stretches the dead air out significantly.
This ties directly into the second issue you mentioned where the agent hangs “waiting for the user” before making the transfer. In Retell’s configuration, custom functions have a toggle called Speak After Execution. When this is disabled, the agent won’t automatically proceed on its own after a function finishes; it will literally sit in silence waiting for the caller to say something before generating its next action (in this case, the transfer).
To get your system running smoothly again, I’d highly recommend looking into these fixes:
1. Process Downstream Tasks in the Background
A good rule of thumb for voice AI is to never block a live conversation waiting on slow external APIs. Instead of making Retell wait for the email and software tool calls to finish completely, your endpoint should instantly return a success response (like a 200 OK) back to Retell so the agent moves forward immediately. You can fire off the actual email and software tool API requests in the background right after acknowledging Retell.
2. Adjust Agent Settings
Inside your Retell custom function settings, make sure to enable Speak After Execution so the agent automatically jumps straight into the transfer transition as soon as the function returns, without requiring user input. You might also want to enable Speak During Execution and give it a short filler phrase (like “One moment while I get that over to the team…”) so there’s no dead air while the server processes the handshake.
Alternatively, if your workflow allows it, the cleanest architectural fix is to move the email and software tool actions out of the mid-call flow entirely and push them to Retell’s post-call webhook (like the call_ended event). If the data doesn’t strictly need to be sent before the transfer happens, moving it post-call means it can never block your live conversation or delay a transfer again.
Check your Retell call logs to see the execution time of that function node, and maybe add some quick timing logs to your backend code to see which of the two downstream services is hitting that 12-second wall!
Let us know if this helps clear up the latency loop or if you run into any other edge cases with it!