> ## Documentation Index > Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt > Use this file to discover all available pages before exploring further. # Troubleshooting: message parked before sending > A state matrix for the four pre-send parking states — scheduled, pending, queued, and quiet-hours holds — with the check and the fix for each, so you stop a row before it sends without guessing which parking state it is in. # Troubleshooting: message parked before sending A message that never sends is parked in one of a small set of pre-dispatch states, and each one has a different cause and a different fix. This page is the state matrix for that pre-send stage: identify which parking state your row is in, then run the check and the fix that belong to it. Distinguish this stage from the post-send stage before you start: a row parked here has **never left Orbit**. A row that reached `sent` and is waiting on a carrier delivery receipt is past the queue — work the [message sent but no delivery receipt](/troubleshooting/submitted-no-receipt) page instead. For the terminology behind every status on the dispatch path, see the [message status transition rules](/concepts/message-status-dag) — the canonical map of which states exist and which transitions between them are legal. ## The four parking states Four states can hold a row before it dispatches, plus one overlay hold. Read them as distinct parking lots, not as one queue: | Parking state | What parks the row | The check | The fix | | ---------------- | --------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `scheduled` | A future `send_at` time you set on the send | Read the row — `send_at` is set and in the future | Expected behaviour; it fires at that time. To fire sooner, cancel it (`POST /api/v1/messages/:id/cancel`) and re-send without a send time, or re-schedule the send at the time you want | | `pending` | The compliance gate — a required compliance profile is not attached or not yet verified | Verify the compliance profile link for the sender or number (`pending_compliance` holds it open) | Attach the missing compliance\_profile, or complete its verification, then re-send | | `queued` | Accepted into the dispatch lane, waiting for free sender capacity | Check the sender pool — every member is at its throughput ceiling or removed | Move the pool's overflow: add warmed senders to the pool, or route through a pool with free capacity | | quiet-hours hold | The fire time fell inside your organization's quiet-hours window | Inspect the quiet-hours window against the recipient's local time | The send re-parks to the next open window (marketing channels) — expected. Widen the window if the hold is wrong, or accept the deferral | A fifth name sometimes surfaces in diagnosis: `accepted`, the synchronous handoff between submission and the dispatch lane. It is transient — a row sitting there for more than a second is investigated the same way as `queued`. ### `scheduled` — the send-at time has not arrived A future send time parks the row in `scheduled` until the time arrives; it then promotes to `queued` and joins the normal dispatch path. The row is fully editable and cancellable until it fires. If the row is still `scheduled` **after** its `send_at` passed, that is no longer scheduling — it becomes a `queued`-lane problem, so continue down the matrix. The [scheduled-send lifecycle](/concepts/send-at-scheduled-sends) page covers the park and drain mechanics. ### `pending` — the compliance gate `pending` means the gate chain has not cleared the send. The blocking gate here is the compliance-profile gate: a sender, number, or template that a regulated destination requires a verified compliance profile for stays at `pending` until that profile is attached and verified. This is a tenant-owned control — the profile is your registration, and the gate holds because the link is missing, not because of a platform-side mandate. Confirm it by reading the row and checking the sender's compliance-profile link; fix it by attaching the missing profile or completing its verification, then re-sending. ### `queued` — accepted, awaiting a free lane `queued` means the gates cleared and the row is in the dispatch lane waiting on capacity. The usual cause is sender-pool exhaustion: every member in the pool the message routes through is at its per-sender throughput ceiling, or has been removed. The [sender pools guide](/guides/sender-pools) shows per-member health; fix it by adding warmed senders to the pool or routing the message through a pool with free capacity. Rarer causes — a provider-side connectivity event or an email IP warm-up cap — park rows the same way; the [message stuck in queued](/reference/troubleshooting) page walks the full cause table for this state. ### The quiet-hours hold A send whose fire time falls inside your organization's quiet-hours window does not dispatch on the spot. On the channels where deferral is the defined behaviour (marketing traffic), the row is re-stamped to the next open instant and held rather than sent into the window. Confirm the hold by comparing the recipient's local time against your configured window; the hold clears at the next window open, or immediately if you widen your window. The [send gating and quiet hours](/concepts/send-gating-and-quiet-hours) page maps the full gate chain this hold belongs to — every one of them a control you configured. ## The corrective action per state Match the fix to the parking state — none of the three fixes helps the other states: * **Reschedule a `scheduled` row** when the hold is the send-at time: cancel it and re-send with the fire time you actually want. Do not resend blindly — a second copy goes out once the original fires. * **Attach the missing compliance\_profile** when the row is `pending`: the gate lifts the moment the profile verifies, and the same row sends. * **Move the pool's overflow** when the row is `queued`: add warmed capacity to the pool, or repoint the send at a pool with headroom. Review the pool's spread afterwards with the [pool-spread alerts](/troubleshooting/sender-pool-spread-alerts) page so the same lane does not starve the next burst. ## When the row is not parked at all If the Delivery Log shows the row reached `sent` but no `delivered` ever landed, it is not queued — it left the pre-send stage entirely, and the hold is on the carrier side of the handoff. That is the post-queue stage, and the diagnosis belongs to the [submitted-no-receipt](/troubleshooting/submitted-no-receipt) page, which covers the per-channel DLR grace windows and how to tell a delayed receipt from an unreachable recipient. ## See also * [Message status transition rules](/concepts/message-status-dag) — the terminology map: what each parking state means and which transitions out of it are legal * [Message stuck in queued](/reference/troubleshooting) — the full cause table and escalation path for the `queued` lane * [Message sent but no delivery receipt](/troubleshooting/submitted-no-receipt) — the post-queue stage, for rows that reached `sent` * [Send gating and quiet hours](/concepts/send-gating-and-quiet-hours) — the full gate chain, including the quiet-hours hold * [The scheduled-send lifecycle](/concepts/send-at-scheduled-sends) — how `send_at` parks the row and how the drain fires it * [Sender pools](/guides/sender-pools) — per-member pool health for the `queued` capacity check