Why did the redials stop after the first call?

Two designed stops: a booking (in-call or made outside a call) removes every scheduled redial for that lead, and an exhausted retry plan tags the contact "Retry plan exhausted (unreached)" with a note. Neither is a fault.

Use the agent's "Send test lead" button (Data & GHL tab): it pushes a lead through the same ingress as the CRM webhooks and returns the whole trace. It is a real, billed call, so use a number you control. Otherwise note the exact webhook response and the timestamps of your test triggers for support.

FAQ

Calls are not firing — full checklist

Q: Where do I start?

From the Operational status strip on the Dashboard (and Initial setup): nine checks that answer "will a call actually fire?" — connections, a number registered on Retell, an active agent with such a number, an active client with a calendar, a lead in the last 30 days. Anything not green there is almost certainly the answer.

Q: Where can I see why a lead was not called?

On the Leads page: a lead that was not called carries a "Skipped: …" badge with the exact reason, and the lead detail shows the last skip with its timestamp. The badge only shows while the skip is more recent than the last call.

Q: Are you inside the calling window?

The window is per agent (agent editor → Retries & transfer → Calling window) or the agency one (Settings → Calling window). Outside it the lead is parked until the next opening — nothing is lost. Two switches escape it: "Even outside the calling window" for first calls and "Call at the agreed time even outside the calling window" for callbacks.

Q: Is Retell connected for your agency?

Credentials are per-agency. Without a Retell connection (Connections page) the dispatcher skips your agency entirely.

Q: Are your numbers registered on Retell?

A number Retell does not know can neither place nor receive calls, whatever you assign. The Numbers page shows a warning banner and a Retell column: press "Register on Retell" on the offending row and read the provider error if it fails. Numbers bought in-app are registered automatically.

Q: Is the client active and does it have a calendar?

An inactive client makes the webhook answer skipped: client_inactive_or_not_found. A client without a calendar answers skipped: not_configured — pick a calendar in the client detail page to activate it.

Q: Is the agent set to Inbound?

An agent whose Direction is Inbound answers call-backs and never dials: triggers pointed at it answer skipped: inbound_agent and queued calls for it are dropped with a queue-drop alert. An outbound campaign needs an "Outbound (places calls)" agent.

Q: Is the lead blocked (Do-Not-Call)?

Leads who asked never to be contacted again are skipped at every entry point (skipped: blocked). An operator can unblock a mistaken DNC from the lead detail page.

Q: Is max concurrency at least 1?

A very low limit throttles dispatch; an invalid value is ignored and the platform falls back to its default (10). The effective ceiling is the lower of the setting and your Retell workspace limit, and the slots reserved for first calls are off-limits to retries by design.

Last updated: September 8, 2026

Leads are being triggered but no call starts? Work through this checklist top to bottom — it's ordered by how often each cause is the culprit. Most "nothing is dialing" cases are one of the first five.

Start from the Operational status strip

The Dashboard (and Initial setup) shows nine checks that answer "will a call actually fire?" — the three connections, a number registered on Retell, an active agent with such a number, an active client with a calendar (its own, or the agent's default), and at least one lead received in the last 30 days. Anything not green there is almost certainly your answer; the sections below explain each case. See The onboarding checklist explained.

Read the lead's own reason

Open Leads: a lead that was not called carries a Skipped: … badge with the exact reason, and the lead detail shows the last skip with its timestamp. The badge only appears while the skip is more recent than the last call, so it never accuses a call that actually went out. This is faster than reconstructing the webhook response.

Are you inside the calling window?

Outbound calls fire inside a calling window that can be set per agent (agent editor → Retries & transfer → Calling window), otherwise the agency one (Settings → Calling window). Outside it nothing is lost: the lead is parked until that window's next opening. Note the two escapes before assuming a fault — an agent may have "Even outside the calling window" on for first calls, and "Call at the agreed time even outside the calling window" on for callbacks; with both off, a 21:00 test on a 09:00–19:00 window fires the next morning, by design.

Is Retell connected for your agency?

Connections are per-agency. Without a Retell connection (Connections page) the dispatcher skips your agency entirely — triggers are accepted and queued, but nothing ever dials. The Connections page shows the live status of all three providers.

Are your numbers registered on Retell?

A number your Twilio account owns is invisible to Retell until it is registered there — it can neither place nor receive calls, whatever you assign in GodSetter. Open Numbers: a warning banner and the Retell column say it outright. Press Register on Retell on the offending row and read the provider error underneath if it fails (calls to a foreign destination also need Voice → Geographic Permissions → Elastic SIP Trunking enabled on Twilio). Numbers bought in-app are registered automatically; numbers bought before that automation existed are the usual suspects.

Is the client active and does it have a calendar?

Check the response your workflow webhook received:

skipped: client_inactive_or_not_found — the sub-account isn't imported yet or is inactive. Run a sub-account sync, open the client, activate it.
skipped: not_configured — the client has no calendar of its own and the agent has no default calendar. Set a default calendar on the agent (Identity & routing), or pick one in the client detail page.
Badge Skipped: no calendar on the lead (Leads page) — the agent's default calendar name was not found in that client's sub-account. Check the calendar's name in GoHighLevel (the match is by name, case-insensitive), or pick the client's calendar by hand. If GoHighLevel was merely unreachable, nothing is lost: the call is parked for a few minutes and retried.

Does the agent have active phone numbers assigned?

The most common cause on a fresh setup. Number assignment is fail-closed: an agent with zero assigned active numbers never dials, ever.

New triggers answer skipped: no_number (and the contact gets the "skipped: no active number" tag, if configured).
Already-queued items for that agent are dropped at dispatch time.

Fix: agent editor → Numbers tab → assign at least one active number, and make sure it is registered on Retell (the tab tags an unregistered one not on Retell).

Is the agent set to Inbound?

An agent whose Direction is Inbound answers call-backs and never dials. Triggers pointed at it answer skipped: inbound_agent, and calls already queued for it are dropped (with a queue-drop alert). Check the agent's Identity & routing tab: an outbound campaign needs an Outbound (places calls) agent. An inbound agent needs no number and no matching niche — it answers the outbound agents ticked under Answers the call-backs of, nothing else.

Is the lead blocked (Do-Not-Call)?

A lead who asked never to be contacted again is blocked everywhere: new triggers answer skipped: blocked, scheduled retries don't fire, inbound calls aren't answered. Check the lead's detail page — a Blocked badge means DNC. An operator can unblock a mistaken DNC from the same page (removing the CRM tag does not unblock the lead).

Is max concurrency at least 1?

Settings → Maximum concurrency caps simultaneous calls for the agency; the effective ceiling is the lower of that setting and your Retell workspace limit. A very low limit throttles dispatch to a crawl; an invalid value is ignored and the platform falls back to its default (10). The Settings page only accepts whole numbers of 1 or higher. Inside the ceiling, the Slots reserved for first calls are off-limits to retries — so retries waiting while new leads go out is the intended behavior, not a fault.

Is there at least one active number in the pool?

Separate from per-agent assignment: if the agency owns no active numbers at all, the dispatcher reports no_active_numbers and skips the tick. Buy or reactivate a number in Numbers.

Are the scheduled jobs actually running?

The first call is placed the moment the lead arrives; the outbound dispatcher then runs every minute as the safety net — retries, scheduled callbacks and calls parked by the calling window all resolve on that tick. If the platform's scheduler isn't firing (visible in the hosting dashboard), parked leads pile up and nothing dials even though everything above is green. This is an operator-level check, not an agency setting.

Any failed rows in the call log?

Open Calls and filter for failed entries; the detail page shows the error. A transient dispatch error is retried up to 3 times, then the item is dropped and an in-app alert appears on your dashboard (and by email — to your alert address, or the agency owner's email if none is set). A pattern of failures usually points at the provider account — e.g. Retell balance or Twilio number status.

The first call went out, but the redials stopped

Two designed stops. A booking — in-call, or made by the contact outside a call — removes every scheduled redial for that lead. The retry plan is exhausted: the agent used every attempt without ever reaching the contact; the contact gets the Retry plan exhausted (unreached) CRM tag and a note. Neither is a fault. See Retry cadence, callbacks and human transfer.

Still stuck?

The agent's Send test lead button (Data & GHL tab) pushes a lead through the very same ingress the GHL webhooks use and returns the whole trace — which gate stopped it, or the call it started. It is a real, billed call on a real lead, so use a number you control; it requires editor on Agents plus the "can spend" permission.

Otherwise, note the exact webhook response your workflow received (enqueued vs skipped + reason) and the timestamps of your test triggers — with those two facts, support can pinpoint the stage where the call stopped.