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 reachedsent and is
waiting on a carrier delivery receipt is past the queue — work the
message sent but no delivery receipt
page instead.
For the terminology behind every status on the dispatch path, see the
message status transition rules — 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:
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 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 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 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 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
scheduledrow 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 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 reachedsent 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 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 — the terminology map: what each parking state means and which transitions out of it are legal
- Message stuck in queued — the full cause table and escalation path for the
queuedlane - Message sent but no delivery receipt — the post-queue stage, for rows that reached
sent - Send gating and quiet hours — the full gate chain, including the quiet-hours hold
- The scheduled-send lifecycle — how
send_atparks the row and how the drain fires it - Sender pools — per-member pool health for the
queuedcapacity check