In short
An SMB was running 60 Zapier workflows and a Retell AI voice agent that dropped calls on transfers and after hours. I migrated every workflow to self-hosted n8n with retry, backoff and dead-letter alerting, then traced the voice agent end to end across webhook respond mode, container timezone, E.164 formatting and unwired Twilio error outputs. Four faults, all reporting healthy. Calls abandoned fell from 25.8% to 0.5%, transfer success rose from 63% to 99.2%, and p95 tool response dropped from 7.4s to 480ms.
Project description
A growing SMB ran its operations on roughly 60 Zapier zaps plus a Retell AI voice agent that kept dropping calls, worst on transfers and after hours. The workflows moved to self-hosted n8n with proper error handling, and the voice agent failures were traced end to end. Four separate faults were found, and every one of them was reporting as a healthy execution.
Tools & Deliverables
- Trace across n8n execution data, Retell call transcripts, Twilio error codes and the container environment
- Migration of 60 Zapier and Make.com workflows to self-hosted n8n with retry, backoff and dead-letter paths
- Retell AI agent repair: webhook respond mode, tool call latency, transfer formatting, Twilio number routing
- Timezone correction on the n8n container, plus pinned zone expressions that survive redeploys
- Failure-path test suite, Slack dead-letter alerting, runbook and Loom walkthrough
The problem
- Callers hung up on silence. 311 of 1,204 inbound calls over 30 days were abandoned, 25.8%, with no error anywhere to explain it.
- Every execution logged as success. A voice agent that stops talking is not an exception, so the n8n execution list showed clean runs while customers were being lost.
- Zapier had been hiding the baseline. Its silent auto-retries meant 14 of the 60 workflows had been failing intermittently for months.
- Transfers failed more than a third of the time. Twilio rejected calls with error 21211, but the error output on the HTTP node was connected to nothing, so the call ended and the run recorded a success.
- After-hours calls went to an empty queue. 188 evening calls were routed to the daytime queue, with no voicemail to catch them.
Approach
The migration came first, because the Zapier account was the only record of what the business actually ran. All 60 zaps were exported and catalogued, trigger, action, filter and formatter step by step, with the ones that had no clean n8n equivalent flagged. That catalogue held the first real finding: Zapier had been quietly normalising phone numbers to E.164 inside a formatter step, and auto-retrying failed tasks without telling anyone. Neither has an automatic counterpart in n8n, so both had to be rebuilt deliberately.
The voice agent was harder, because nothing reported an error. Retell's call transcripts, the n8n execution data and Twilio's call logs were lined up for the same calls. The transcripts showed the agent going quiet mid sentence, while n8n showed the same runs succeeding slowly, with a p95 of 7.4 seconds. Retell abandons a custom function that has not answered in 3 seconds, and the webhook was set to respond only when the last node finished, so callers waited through a three call HubSpot lookup. The same comparison exposed the missing container timezone and the bare ten digit transfer numbers. Each fix went in separately so it could be verified on its own.
Solution
The agent now answers Retell in 480ms at p95, well inside the 3 second budget, and the slow CRM enrichment continues on a branch the caller never waits for. Abandoned calls fell from 311 to 6 across the same 30 day sample, 25.8% down to 0.5%. Transfers succeed 99.2% of the time, with the rest absorbed by retries rather than lost. After-hours routing is correct and survives a container redeploy, because the zone is pinned in the expression as well as the environment.
The part worth more than the patch is that failure is now visible. Anything that exhausts its retries posts to a Slack dead-letter channel with the call SID, the Twilio error code and the retry count. All 60 migrated workflows ship with their error branches exercised, not just their happy paths, and the handover is a written runbook plus a Loom walkthrough so the in-house team owns it.
FAQ
How was the bug found in the first place?
By lining up three systems that each looked fine on their own. Retell showed the agent going silent, n8n showed those executions succeeding, and Twilio showed rejections that n8n had recorded as successes.
Was this one issue or several?
Four, with overlapping symptoms: webhook respond mode, a missing container timezone, missing E.164 formatting, and an error output wired to nothing that made all three look like successful runs.
Did you only diagnose, or also fix?
Both. The 60 workflows were rebuilt in n8n with retry and dead-letter paths, the webhook and timezone configuration corrected, E.164 normalisation added, the Twilio error output rewired and failure-path tests written.
How do you stop it happening again?
Dead-letter alerting plus tested error branches, so the next failure announces itself, and a daily reconciliation that checks every call against its expected end state.
How would you explain it to a non-technical owner?
About one in four callers hung up before reaching anyone, and the system recorded those calls as handled. Four small settings caused it. All four are fixed, and problems now raise an alert within seconds.
