Skip to main content

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 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 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 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 page, which covers the per-channel DLR grace windows and how to tell a delayed receipt from an unreachable recipient.

See also