Call ID: 019b99bd-c59c-7993-9b79-87016b2eada4 Scheduled Time: Jan 8, 2026, 12:05 AM Expected Response: The call should be initiated at the scheduled time. Actual Response: The campaign is still showing “Scheduled” status. The scheduled date and time have already passed, but the call has not been initiated. Could you please check why this call was not initiated and provide a resolution as soon as possible? https://cdn.discordapp.com/attachments/1458742135527309312/1458742135703605362/Screenshot_from_2026-01-08_13-48-46.png?ex=698d91fb&is=698c407b&hm=16acd3170ee845239aefd12e75d363216a52132aa316ba68079454452c51442a&

Your campaign may be stuck in "Scheduled" status due to reaching your organization's concurrency limit. To resolve this, go to your Vapi Dashboard and navigate to Settings → Billing → Reserved Concurrency (Call Lines), then increase your concurrency limit or purchase additional call lines. This change takes effect immediately and should allow your scheduled calls to proceed. For more details, see the [Vapi concurrency documentation](https://docs.vapi.ai/calls/call-concurrency). Source: - [Understanding Call Concurrency](https://docs.vapi.ai/calls/call-concurrency)

We have a campaign with only 1 outbound call and concurrency limit is 10. No other campaigns or calls were running at the same time. However, the call never reached the customer (pickup = 0, voicemail = 0). Can you please check if there was any internal dial queue delay, carrier rejection, or assistant/workflow initialization issue for this call?

Hey Azhar, I’ve checked your call details. The earliestAt and latestAt timestamps have only about a two-minute gap: • `earliestAt`: 2026-01-07T18:35:10.000Z • `latestAt`: 2026-01-07T18:37:08.000Z During peak load, calls can sometimes be delayed and may not start exactly at the earliestAt time. This is a known issue, and the team is already planning a fix. Since the latestAt time was very close, the call was not placed as the window had already passed. As a solution, we recommend increasing the gap between earliestAt and latestAt to allow more buffer.

What is the recommended minimum time gap between earliestAt and latestAt that you suggest we use?

That depends on your use case; I suggest setting it at high as you can, or just remove that value if not much needed.

We implemented earliestAt because earlier we faced a delay issue where the VAPI outbound call log continued to show “scheduled” even after the scheduled time had passed, and in one case the call was received 28 minutes after the scheduled time. This issue doesn’t happen consistently, but we’ve observed it multiple times around 12:05 PM Chicago time. If we remove earliestAt, is there a chance this delay issue will occur again? If so, is there any recommended alternative solution to prevent delayed call execution?

HI Azhar, Yes, the delay issue is inconsistent; it happens in peak loads. The team will fix this issue in Q1 2026. I can't guarantee this won't happen if you remove earliestAt. If the call is time sensitive, and can't be afforded to be called later, please keep earliestAt as the last time we're allowed to call. If you keep earliestAt, and due to tge delay that time passed, it'll