Let deliveries wait for capacity.
When concurrency or the rolling hourly attempt allowance is full, a Letter or Letterflow can wait in your account queue. The queue is shared across regions, dashboard sends, API runs, and eligible schedules. Waiting deliveries survive restarts and have no automatic expiry.
Choose what can wait
Save your queuing preferences in Settings. The Schedule page also shows whether scheduled queuing is currently enabled.
| Setting | Default | Effect |
|---|---|---|
| Queue deliveries when capacity is full | On | Dashboard and integration API sends may wait for capacity. |
| Also queue scheduled deliveries | Off | Schedules may join the queue when the main setting is also on. |
The scheduled-delivery setting is disabled while the main setting is off, but its saved value is preserved. Turning either preference off affects new submissions only; previously accepted waiting deliveries continue.
With applicable queuing off, a submission that cannot be admitted receives an immediate capacity error. Earlier waiting work also prevents a new delivery from jumping ahead, even if the new delivery needs fewer attempts.
Settings โCapacity and admission order
Each Letterflow occupies one waiting position. Waiting capacity is twice your effective concurrent-run limit, including account-specific exceptions.
| Plan | Concurrent runs | Waiting deliveries |
|---|---|---|
| Tinkerer | 1 | 2 |
| Aspiring | 3 | 6 |
New deliveries join the end and are admitted in the displayed order. An entry blocked by allowance, account policy, or regional availability holds its place. Later entries cannot bypass it; move or remove the blocked entry to let them proceed. Concurrently admitted deliveries may finish in a different order.
If your queue limit decreases, existing entries remain. New entries are rejected while the queue is at or above the reduced limit. Increasing waiting capacity does not increase execution throughput.
A waiting delivery uses no concurrency slot or hourly attempts. Admission reserves the complete run budget, including retries, redirects, and the longest possible Letterflow path. A Letterflow uses one account slot until settlement; its internal Letters do not rejoin this queue or acquire extra account slots.
Admission is retried after capacity changes and about every five seconds. Execution timeouts start at admission, independently of time spent waiting. An indefinite wait does not guarantee success: invalid inputs can fail, restrictions can block admission, and credentials or the requested action can become stale.
Review, reorder, or remove
- Open the queue.
Click Queue in the dashboard usage panel. The waiting/limit count expands a list with each delivery's position, submission source, waiting duration, and blocking reason.
- Move up or Move down.
Change the admission order of waiting deliveries. If the queue changed before your reorder arrived, it refreshes instead of overwriting the newer order.
- Remove a waiting delivery.
Successful removal guarantees that delivery will not execute. If it was already admitted, removal reports a conflict; use Stop in Delivery activity instead. Stopping admitted work cannot undo an outbound operation.
Each new Send creates a separate delivery, even if the same Letter or Letterflow is already running or waiting. Double clicks and retries of the same rendered form reuse its run. API requests with distinct idempotency keys and separate scheduled occurrences create separate deliveries.
What a waiting delivery keeps
Submission freezes execution options and references to regional inputs. Later edits to a Letter, Delivery Policy, Letterflow, or schedule do not rewrite an accepted delivery. To use edited settings, remove the waiting delivery and submit a new one.
Request content stays encrypted in its assigned execution regions; Letterflow definitions stay in the Coordinator region. Queuing does not relocate that content through Hub. Waiting references protect required inputs from cleanup. Removal releases those references, while inputs still used by saved resources or admitted work remain protected.
Deleting a saved Letterflow or required dependency cancels its affected waiting deliveries. Already admitted work keeps its protected snapshot. Short-lived execution permissions are issued at admission, so a long wait does not rely on an expired permission from submission time.
Scheduled occurrences
Both queuing preferences must be on for schedules to share the account queue. Pausing or deleting a schedule cancels its waiting occurrences; already admitted work continues. Editing a schedule affects future occurrences, not snapshots already accepted.
One-time and finite-repeat schedules
At most one occurrence per schedule may wait. Waiting does not consume a repeat. Admission consumes the occurrence and calculates the next repeat from admission time using the configured interval.
Removing a waiting repeat skips one occurrence without making an outbound attempt, then schedules the next remaining occurrence after the interval. Removing a waiting one-time occurrence finishes the schedule without delivery. Paused schedules never resume automatically.
Cron schedules
When creating or editing a cron schedule, choose what happens when an occurrence is already waiting.
- Keep one pending occurrence
- The default: retain the original snapshot and queue position, skipping further ticks while it waits.
- Queue each occurrence
- Append a separate snapshot for each observed due occurrence, up to the shared queue limit.
You can save the cron preference while scheduled queuing is off; it takes effect only when both account preferences are on. Changing it does not merge or remove existing entries. A full queue skips a new cron occurrence and records the capacity denial. Missed ticks during scheduler downtime are not backfilled.
Waiting in the integration API
A new submission returns 202, including a waiting one; an idempotent replay returns 200. Replaying an accepted key returns the same run even after cancellation. Use a new key for a new delivery.
| Run state | Meaning |
|---|---|
waiting | Waiting for account capacity; not an execution failure. |
queued | Admitted and pending regional execution; capacity is reserved. |
Poll the run for queue_position, wait_reason, and admitted_at. A full waiting queue returns HTTP 429 with error.code=queue_full. Reordering and removal use the authenticated dashboard session; integration keys gain no queue-management permissions.
Submit and poll a run โ