The scheduled queue
Everything automated email is about to do, in one list, with a reason attached to anything that isn't simply pending.
Every automated send is a real row in the queue — from sequences and from flows alike. One pipeline means guards, send windows, pacing and cancellation all apply to everything, and nothing is invisible.
Long-term scheduling lives in these rows, never in a queue of delayed jobs. A background worker only ever does what's due in the next minute, so the future stays inspectable and cancellable, and losing a worker for a day delays work rather than losing it.
Statuses
| Status | Meaning |
|---|---|
| Pending | Waiting for its due time. |
| Held | Due, but something is stopping it. The reason — and the guard, if it's a guard — is on the row. |
| Dropped | It will not be sent, and why. |
| Canceled | Someone or something called it off. |
| Sent | Handed to the provider. |
A hold is a reason, not an outcome. Held rows are re-checked every minute, so one goes out in the minute its reason clears.
Why something is held
- Held by a guard — a Pause & wait guard matched. The guard's name is on the row.
- Its sequence is turned off
- Its flow is paused
- Outside its send window — with the due time moved to the next open slot, so you can see exactly when it will go.
What each row tells you
Who it's for, which email, what scheduled it (linking to that sequence or flow), its status and reason, and when it's due. You can cancel any pending or held row from here or from the person's own page; the rest of their run carries on as scheduled.
Filter by status, sequence, flow, or the guard doing the holding — the last one answers "what is this guard actually stopping?" in one click.
The sending pipeline
When a row comes due, the checks run in a fixed order, and the order matters:
- Suppression. Unsubscribed people don't get automated email. Nothing gets past this, ever — a person who unsubscribed an hour ago is never even asked whether a guard applies to them.
- Guards. Your own send-time checkpoints. When several match, the most severe action wins.
- The send window. Outside it, the row is held and its due time moves to the next open slot.
- Pacing. Sends are kept inside the provider's declared per-minute limit, shared with one-off sends because the provider counts them the same way.
- Send. Compile, personalize, hand to the provider, record what came back.
A failure leaves the row in the queue with the provider's error visible, so you can see what actually went wrong. After three attempts it's dropped rather than retried forever.
Send windows
Settings → Sending sets the days and hours automated email is allowed to go out. With no rules configured, everything sends whenever it comes due.
An email due outside its window isn't dropped or rushed — it's held, and its due time moves to the next open slot.
A rule can be scoped to an email label, and a label rule wins over the global one. That's how "drip emails wait for business hours, delivery emails go the moment they're earned" is expressed: put the window on the drip labels and leave receipts and downloads unscoped.
This is a knob, not code. Changing a window changes when everything already queued will go, with the new due times visible in the queue straight away.
Named durations
The same settings page holds the named durations flows can wait on
({ "setting": "quiet_buffer_days" }). Each one lists the flows
using it, so renaming or deleting one isn't a guess. Changing the number
changes every flow that waits on it, immediately, without touching a
definition.