Significant call delay

Support Help
1

Good day!
Could you please assist in investigating a delay in batch call executions? We noticed a significant time gap between the task creation time and the actual dispatch time for the following examples:

Example 1:Batch ID: batch_call_61408c5007501298e890c
Created at: 8/31/2026, 8:10:20 AM
Sent at: 8/31/2026, 10:09:57 AM
Delay duration: ~1 hour 59 minutes

Example 2:Batch ID: batch_call_4240754b981d50777cb0d
Created at: 8/31/2026, 8:26:56 AM
Sent at: 8/31/2026, 10:46:11 AM
Delay duration: ~2 hours 19 minutes

Could you please check your system logs and clarify why these tasks were queued for around 2 hours before being processed?Looking forward to your response.

2

@1.menshikovzvon.job2 Could you please share your Org ID? This will help us look into the issue further.

Thank You

3

org_iN5bBD21PHfDNTLw

4

@1.menshikovzvon.job2 I’m checking your Org ID with the team and will get back to you as soon as I have an update.

Thank You

5 
Good afternoon! Could you tell me if there is any news?
6

Good afternoon again! Is there any answer regarding the question above?

7

@1.menshikovzvon.job2 I’ve escalated your issue to the team, but I don’t have any further information or updates yet. I’ll get back to you as soon as I hear back from them.

8

Hello @1.menshikovzvon.job2 Team checked org org_iN5bBD21PHfDNTLw and both batch IDs.

  • Both batches were created as send-now, one-task batches, and the task rows were created immediately after the batch timestamps.
  • The send-now enqueue step completed immediately for batch_call_61408c5007501298e890c at 08:10:20 UTC; the second batch shows the same task-created-then-later-call-created pattern in the batch/task/call records.
  • The outbound calls were created/started later: call_d444ce375bd48821c757dfd0bfb at 10:10:05 UTC and call_1203fcaa7b373348d467069606d at 10:46:36 UTC.
  • The numbers used are custom-provider numbers, and dispatcher logs showed no crash or timeout during the incident.

This was not a missed batch or failed enqueue. The delay occurred after the task entered the outbound execution queue, before the call was created. If lower latency is needed, review the workspace’s custom-provider outbound capacity/CPS and the volume of send-now batches launched into the same queue before recommending config changes.

Since all your batch calls contain only one call, I recommend using the create phone call API instead, as calls go out immediately:

Thank You

9

Thank you for the detailed breakdown.
Given our current campaign intensity and the volume of broadcasts we run, what specific steps would you recommend to prevent such queuing delays in the future?

We would also appreciate your comments on the following issues:

  1. Capacity limits: Are there any outbound capacity or CPS adjustments needed for our custom provider?
  2. API optimization: You mentioned switching to the create phone call API — Will requests made via the create phone call API be prioritized over batch calls, or do they share the exact same outbound execution queue?
  3. Queue monitoring: Is there a way for us to track the outbound execution queue latency on our end?

Looking forward to your guidance to help us keep latency as low as possible.

10

Hello @1.menshikovzvon.job2

  • To increase CPS, you need 20 concurrency units per 1 CPS; for 2 CPS, you need 40 concurrency units.

  • Calls made via the create phone call API are executed almost immediately.

  • Currently, there is no way to monitor outbound execution queue latency on your end.

For your case, the best option is to send calls using the create phone call API.

Thank You