Outbound call stuck in registered for 24h+ — never placed, no webhooks emitted

Support Help
1

Summary

A phone call we created via POST /create-phone-call was accepted by Retell and assigned a call_id, but never transitioned past call_status: “registered”. The outbound leg appears to
have never been placed: no start_timestamp, no end_timestamp, no disconnection_reason, total_duration_seconds: 0, latency: {}. We also never received any webhook for this call
(call_started, call_ended, call_analyzed — none). All other calls in the same minute against the same webhook endpoint were delivered normally.

Identifiers

  • call_id: call_248c006d0bca5529b15523941d7
  • agent_id: agent_12d66a9ad7a6335ad45c074ee8 (agent name: Andrea (Recaudo) Mayo 26, agent_version: 0)
  • from_number: +576013789734
  • to_number: +573223991581
  • direction: outbound
  • Our internal IDs (in Retell metadata): callId=403282f4-97ae-470d-ab31-4141009a675a, targetId=1063228, campaignId=15715
  • Created at: 2026-05-26T21:34:14.751Z (UTC)
  • Verified still registered at: 2026-05-27 (today), ~24h later

Timeline (our side, all UTC 2026-05-26)

┌────────────────────┬───────────────────────────────────────────────────────────────────────────────────────┐
│ Time │ Event │
├────────────────────┼───────────────────────────────────────────────────────────────────────────────────────┤
│ 21:34:14.521 │ Dispatch scheduled for target 1063228 │
├────────────────────┼───────────────────────────────────────────────────────────────────────────────────────┤
│ 21:34:14.632 │ We called Retell createPhoneCall │
├────────────────────┼───────────────────────────────────────────────────────────────────────────────────────┤
│ 21:34:14.751 │ Retell responded 200 OK with call_id=call_248c0…, call_status=registered │
├────────────────────┼───────────────────────────────────────────────────────────────────────────────────────┤
│ 21:34:14.785 │ Internal CallCreatedEvent recorded; nothing more to do until a Retell webhook arrives │
├────────────────────┼───────────────────────────────────────────────────────────────────────────────────────┤
│ After 21:34:14.785 │ No further activity. No webhook ever received for this call_id. │
└────────────────────┴───────────────────────────────────────────────────────────────────────────────────────┘

Current Retell API response (GET /v2/get-call/call_248c006d0bca5529b15523941d7, fetched 2026-05-27)

{
“call_id”: “call_248c006d0bca5529b15523941d7”,
“call_type”: “phone_call”,
“agent_id”: “agent_12d66a9ad7a6335ad45c074ee8”,
“agent_version”: 0,
“agent_name”: “Andrea (Recaudo) Mayo 26”,
“call_status”: “registered”,
“from_number”: “+576013789734”,
“to_number”: “+573223991581”,
“direction”: “outbound”,
“metadata”: {
“callId”: “403282f4-97ae-470d-ab31-4141009a675a”,
“targetId”: 1063228,
“campaignId”: 15715
},
“call_cost”: { “total_duration_seconds”: 0, “combined_cost”: 0, “product_costs”: },
“latency”: {},
“data_storage_setting”: “everything”,
“opt_in_signed_url”: false,
“custom_sip_headers”: {}
// no start_timestamp, no end_timestamp, no disconnection_reason,
// no transcript, no recording_url, no error_* fields
}

What we’ve already verified on our side

  • the call creation returned 200; payload (agent, from/to, dynamic variables, metadata) was accepted by Retell with no error.
  • Our webhook endpoint was up and processing other Retell webhooks normally in the same minute and throughout the hour — many other calls for the same agent/account completed
    end-to-end with call_ended events delivered.
  • No retries or duplicate createPhoneCall requests for this to_number/call_id from our side.
  • The retell UI Dashboard does not show info for call call_248c006d0bca5529b15523941d7

What we’re asking

  1. Why did call_248c006d0bca5529b15523941d7 never progress past registered? Was the outbound leg ever attempted on the telephony side?
  2. If it failed pre-dial (carrier/SIP/agent issue), why was there no disconnection_reason recorded and no call_ended webhook emitted?
  3. Is there a class of failure where Retell allocates a call_id but never places the call and never emits a terminal webhook? If so, what’s the recommended client-side reconciliation
    pattern (polling cadence, status to treat as terminal)?
2

Hello @david4 I’ve escalated this issue to our team for further investigation.

We’ll keep you updated as soon as we have more information.

Best regards

3

Hello @david4

Here’s what happened with call_248c006d0bca5529b15523941d7:

  • The call was accepted and queued for dispatch (the 200 you saw and the registered row).
  • The internal worker that was supposed to place the outbound leg was interrupted before it could initiate the SIP dial. With current config, an interrupted job of this type is dropped rather than retried — so no SIP INVITE was ever sent to your Twilio Elastic SIP trunk, and no call_startedcall_ended webhook fired (those events emit from inside the call lifecycle, which never began).
  • Sibling calls on the same from_number in the same minute went out normally — isolated to this one queued job, not your trunk, agent, or webhook endpoint.

Direct answers to your questions:

  1. The outbound leg was never attempted; no INVITE left our infrastructure.
  2. No disconnection_reason or terminal webhook because the call never entered the in-call state machine that emits those. We’ve identified this as a gap on our side for this specific failure class and will be addressing it on the engineering side.
  3. Yes — this is a rare but recurring class where a call_id is allocated but the dial never occurs and no terminal webhook fires. Recommended client-side reconciliation:
  • Poll GET /v2/get-call/{call_id} every ~5s after create-phone-call returns.
  • Treat call_status in ended, error, not_connected} as terminal.
  • If call_status is still registered and start_timestamp is null after ~60s, treat as orphan, mark failed on your side, and re-issue create-phone-call. Safe to retry — orphan rows hold no concurrency or telephony leg.

Happy to back-mark this specific row to errored so it stops appearing as registered in your reconciliations — just let us know.

Thank You