Queue & reliability
The queue tells you before it fails. Not after, in an email you read on Monday.
Every scheduler shows you a list of upcoming posts. The interesting part is what happens when something goes wrong — an expired token, a worker that dies mid-publish, an outage that backs up a day of posts. Those cases are the ones that decide whether you trust the tool.
Every state visible, every failure retryable.
Capabilities
What you get with Queue & reliability.
- At-risk posts are flagged early
- A scheduled post whose channel is disconnected, whose token has expired, or whose workspace has no active subscription shows as at risk before its publish time. You learn while you can still fix it.
- Late posts are held, not dumped
- A post more than an hour past its slot is marked as having missed its window instead of publishing. After an outage you get a list to triage, not yesterday evening’s post going out this morning as if nothing happened.
- A crashed publish becomes retryable
- Publishing claims a row atomically so it can never double-post. If the worker dies holding a claim, a reaper releases it after 15 minutes and marks it failed-but-retryable, rather than leaving a row nothing can touch.
- Holds are not failures
- A disconnected channel or a lapsed subscription holds your posts as scheduled rather than failing them. Reconnect or pay and the whole queue resumes — there is nothing to rebuild by hand.
The states a post moves through
DRAFT → SCHEDULED → PUBLISHING → PUBLISHED
↘ ↘
held FAILED (retryable)
A dated draft sits on the calendar with a time but can never publish. That is what a free workspace's calendar is made of, and what a client sign-off flow produces before approval.
Scheduled is a real promise to publish. Moving a draft to scheduled is always an explicit act, and it is what charges the post against your monthly per-platform quota.
At risk, before the deadline
An at-risk post is one that cannot publish yet:
- its channel was disconnected,
- its token expired and needs a reconnect,
- or the workspace has no active subscription.
None of those are the post's fault, so none of them fail the post. It stays scheduled and is surfaced as at risk in the dashboard. The state is derived from a join rather than stored, which is a boring implementation detail with one useful consequence: there is no third status that can get out of sync with reality.
An expired token and a disconnected channel are different things. "Disconnected" only ever means you removed the channel. A token that has gone stale shows as expired with a reconnect button — the system never disconnects a channel on your behalf.
Why an hour is the cutoff
Without a lateness cutoff, a worker outage ends the same way every time: the backlog clears all at once, hours late, and each post reports success.
That is worse than silence. A morning post landing at midnight is off-brand, and being told it went out fine means you do not even know to look.
So a post more than an hour past its slot is not eligible to publish. A sweep marks it as having missed its window, and it shows up as something to decide about rather than something that already happened.
Claims, and the reaper
Publishing has to be idempotent, so an attempt claims its row with one atomic conditional update — SCHEDULED to PUBLISHING, only if still SCHEDULED. Two workers racing means exactly one wins.
The cost of that design is a worker killed mid-publish: the claim stays behind, and the row becomes untouchable. The publish path refuses a row that is already publishing, retry refuses anything not yet failed, and the composer refuses to edit it.
A claim older than 15 minutes is therefore treated as abandoned. The row becomes a failure that needs a manual check, which is retryable like any other. Nothing gets permanently stuck.
Found this useful? Pass it on.
Questions
Frequently asked questions Everything the first evaluation usually needs.
- What happens if a post fails to publish?
Transient failures are retried with backoff. Anything that settles as failed appears in the activity feed with the platform’s own error and a one-click retry. Unrecoverable failures, such as a revoked token, also trigger an email.
- What if my channel disconnects while posts are queued?
Those posts are held, not failed. They stay scheduled and are shown as at risk, and reconnecting the channel resumes all of them at once. Nothing needs re-creating.
- What happens after an outage — do all my posts publish at once?
No. A post whose slot passed more than an hour ago will not publish. It is marked as having missed its window. Publishing yesterday’s post this morning, with a normal success message, is worse than not publishing it.
- Can a post ever be published twice?
No. A publish attempt wins the row with a single atomic conditional update, so only one attempt can ever proceed. That is what makes retries safe.
- Why does a failed post show a code rather than a raw error?
Each failure carries a stable reason code, which is what gets shown and translated. The raw text the platform returned is kept alongside it for support, so nothing is lost.
- Can I edit a post that is currently publishing?
No — once an attempt has claimed a post, it is locked until the attempt settles. If a worker dies mid-attempt, the claim is released automatically after 15 minutes and the post becomes retryable.
Keep reading
- Activity logOne feed of what happened: every publish, every failure with the platform’s own error, and a one-click retry, for when a client asks about last Tuesday.Read
- Bulk schedulingUpload up to 50 posts at once from a CSV or a folder of media, stagger them automatically at a fixed interval, then review each row before it is scheduled.Read
- Posting timesRecommended posting windows per platform, weighted by strength and resolved in your time zone. Drop a post into the next good slot from the composer or CLI.Read