> ## Documentation Index
> Fetch the complete documentation index at: https://docs.voxworks.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Dispatch, Concurrency & Delays

> How scheduled calls move from the queue to a live dial: the dispatch window, dispatch status messages, concurrency slots and rate limits, delay warnings, and the difference between transient and permanent dispatch failures.

## Overview

Every scheduled outbound call — whether you created it in the **New Call** modal, launched it from a batch, or triggered it from an automation — is dialled by the Voxworks dispatch engine. Dispatch is the short journey between *"this call is due"* and *"this call is ringing"*: the engine picks the call up as its scheduled time arrives, checks that your team has a free calling slot, and hands it to the calling infrastructure.

Most of the time this takes seconds and you never think about it. This page explains what happens when you *do* need to think about it: how calls are claimed for dialling, what the dispatch status messages mean, why a call can show as delayed, and which failures retry themselves versus which need you to act.

For the full list of call statuses, end reasons, and outcomes, see [Call Statuses, End Reasons & Outcomes](/calls/statuses) — this page covers only the dispatch leg of the journey.

***

## The dispatch window

A scheduled call doesn't wait until the exact second of its scheduled time. It **enters the dispatch queue about two minutes before** it is due, and the engine then dials it as soon as your team has capacity. In practice this means calls connect at or very slightly before their scheduled time rather than late.

While a call is still in the future, its dispatch status shows a countdown to the moment it will enter the queue:

* More than about two hours out, the status simply reads **Scheduled**.
* Between two hours and ten minutes out, the countdown steps down in roughly five-minute increments — for example *Will enter dispatch queue in \~25 min*.
* Inside the final ten minutes, it counts down minute by minute.

The countdown refreshes about once a minute, so don't worry if it appears to skip a step.

### Queue order

When several calls are due at once, the queue is worked highest-priority account first, then earliest scheduled time first within each account. Priority is an account-level setting managed by Voxworks — see [Priority tiers](#priority-tiers) below.

### Claiming: Scheduled → Queued → In Progress

When the engine picks a call up, it **claims** it atomically: the call's status moves from **Scheduled** to **Queued**, and only then is the dial started, after which the call becomes **In Progress**. Claiming is what makes cancellation race-free:

* If you cancel a call (or pause its batch) **before** the claim lands, your action always wins — the call will not dial.
* Once a call has been claimed and shows **Queued**, dialling is already underway and it can no longer be cancelled. The Queued state normally lasts only a moment.

Batch calls follow two extra rules at dispatch time:

* Calls belonging to a **paused batch** are held — they stay **Scheduled**, untouched, and are reconsidered as soon as you click **Resume Scheduler**. See [Batch Scheduling](/batches/scheduling).
* Calls belonging to a **cancelled batch** are never dialled — any stragglers the cancellation missed are swept to **Cancelled** by the dispatch engine itself.

***

## Dispatch status messages

Alongside its main status, every scheduled call carries a short **dispatch status** — a plain-text note recording exactly where it is in the dispatch process. Dispatch statuses are stored on the call record and are available through the API as the call object's `dispatch_status` field.

| Dispatch status                           | When you see it                                                                                              | What happens next                                                                                              |
| ----------------------------------------- | ------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------- |
| **Scheduled**                             | The call is more than about two hours from entering the queue.                                               | The countdown starts as the call gets closer.                                                                  |
| **Will enter dispatch queue in \~25 min** | Between ten minutes and about two hours out; steps in five-minute increments.                                | Refreshes about once a minute.                                                                                 |
| **Will enter dispatch queue in 3 min**    | Inside the final ten minutes; counts down per minute.                                                        | The call enters the queue about two minutes before its scheduled time.                                         |
| **\< 1 min, in dispatch queue**           | The call is due, and is waiting briefly for a free platform slot.                                            | Dispatches within moments as capacity frees.                                                                   |
| **DELAYED, rate limited**                 | Your team has reached its hourly outbound calling rate.                                                      | The call waits its turn and dispatches automatically as the hourly window rolls forward. No action needed.     |
| **DELAYED, concurrency limited**          | Your team already has its maximum number of simultaneous calls in progress.                                  | The call dispatches automatically as soon as one of your active calls ends. No action needed.                  |
| **dispatch failed**                       | A dispatch attempt hit a temporary error (for example a brief network fault).                                | The call is released back to **Scheduled** and retried automatically — usually within seconds.                 |
| **Failed to dispatch: (reason)**          | The call can never be dialled as it stands — for example, no outbound number is configured for your account. | The call is marked **Failed**. Fix the cause, then schedule a fresh call.                                      |
| **Dispatched**                            | The call has been handed to the calling infrastructure.                                                      | The call shows **In Progress** — watch it live in [Live Calls & Real-Time Monitoring](/calls/live-monitoring). |
| **Cancelled**                             | The call was cancelled before it dialled — including residual calls from a cancelled batch.                  | Nothing dials.                                                                                                 |

***

## Concurrency slots and rate limits

Two account-level limits govern how quickly your scheduled calls dispatch:

* **Concurrent calls** — how many of your calls can be live at the same time. Your plan lists a concurrent-call figure on its plan card under **Settings → Billing** (see [Plans, Tiers & Feature Gates](/billing/plans)), but the limit actually enforced against your account comes from your priority tier — see [Priority tiers](#priority-tiers) below. When every slot is busy, the next due call shows *DELAYED, concurrency limited* and dispatches the moment a slot frees.
* **Hourly calling rate** — how many outbound calls your team can start per hour. Calls in progress count towards the rate alongside recently completed calls. When the rate is reached, due calls show *DELAYED, rate limited* and dispatch as the hourly window rolls forward.

Three things worth knowing about how these limits behave:

* **Delays are queues, not failures.** A delayed call is never dropped — it keeps its place and dispatches automatically the moment capacity frees. You never need to reschedule a delayed call.
* **They apply to scheduled outbound calls only.** Inbound calls are answered immediately, and the platform reserves dedicated capacity for inbound, web, and test calls, so a busy outbound queue never blocks your [AI Receptionist](/receptionist/overview) from picking up.
* **Voxworks keeps queues moving.** When the wider platform has spare capacity, delayed calls may be dispatched ahead of the strict limit rather than left waiting — so you may occasionally see slightly more simultaneous calls than your slot count.

### Priority tiers

Underneath your plan, each account carries a **priority tier** that sets its hourly calling rate, its concurrency allowance, and its place in the dispatch queue when the platform is busy. Tiers are set on the account by Voxworks and have no in-app control. If you're planning a large campaign and need higher call concurrency or faster dispatch rates, speak to the Voxworks team for further custom configuration.

***

## Delay warnings

You don't have to watch the queue to know a call is waiting:

* The call's dispatch status updates in place — *DELAYED, rate limited* or *DELAYED, concurrency limited* — and keeps updating as the queue moves.
* Voxworks raises **Dispatch delays** as an in-app notification event. You can mute it (or unmute it) under **Settings → Notifications**, alongside events like **Call completed** and **Batch started**. See [Team Settings & Notifications](/team/settings) — notifications are currently in beta, available to selected invites only.

Occasional delay warnings during a busy batch are normal and resolve themselves. Persistent delays across every batch you run are the signal that your team has outgrown its current capacity — see [Priority tiers](#priority-tiers) above.

***

## Transient vs permanent failures

Dispatch distinguishes sharply between problems that will fix themselves and problems that won't:

* **Transient failures retry automatically.** If a dispatch attempt fails partway — a momentary network fault, a busy downstream service — the claim is released, the call returns to **Scheduled** with the dispatch status *dispatch failed*, and the engine retries it on its next pass, usually within seconds. You don't need to do anything, and the call keeps its scheduled time.
* **Permanent failures are marked Failed.** If the call can never succeed as configured — most commonly because no outbound number is set up for the account — it is marked **Failed** with the dispatch status *Failed to dispatch:* followed by the reason. These calls are not retried: fix the underlying cause (for example, add a number under [Numbers & Routing](/numbers/overview)), then schedule a fresh call.

Note this covers failures *before* the call connects. What happens when a dialled call goes unanswered, hits voicemail, or drops out is covered on [Call Statuses, End Reasons & Outcomes](/calls/statuses), and automatic retries for batch calls are covered in [Calling Rules](/batches/calling-rules).

***

## Next Steps

* [Call Statuses, End Reasons & Outcomes](/calls/statuses) — the canonical reference for every status a call moves through, including per-status cancel and retry rules.
* [Scheduling & Managing Calls](/calls/scheduling-calls) — create one-off calls, and learn the pre-flight checks that run before a call is accepted.
* [Batch Scheduling](/batches/scheduling) — how batches pace large volumes of calls across business-hours windows within these same limits.
* [Plans, Tiers & Feature Gates](/billing/plans) — what each plan includes, including concurrent call slots.