How publishing works
Behind every scheduled and published post is a durable publishing engine. It waits for the scheduled moment, delivers the post to each platform, retries transient problems, and gives up fast on permanent ones — all without you keeping the app open. This page explains what happens after you hit schedule.
Scheduled delivery is durable
When you schedule a post, Buzzator starts a durable workflow for it. The workflow sleeps until the scheduled time and then publishes the post. Because the wait is durable, it survives restarts and outages on our side — closing your browser (or a server hiccup) doesn't cancel the delivery. When the time comes, the post is sent and its result is recorded.
Each platform has its own lane
Delivery is routed to a per-platform queue — Instagram posts go through the Instagram lane, LinkedIn posts through the LinkedIn lane, and so on. This isolation means one network's outage can't stall the others: if Instagram is down, your LinkedIn and X posts still go out on time.
Outcomes
When the engine publishes a post, it lands in one of three states, and the result is logged to the post's activity:
| Outcome | Meaning |
|---|---|
| Published | Delivered successfully. |
| Partial | A multi-target post (e.g. a thread or carousel) where some parts went live and some didn't. |
| Failed | Delivery didn't succeed. |
Retries and fast failures
Not every failure is worth retrying, so the engine tells the two apart:
- Transient problems — a network blip, a temporary platform error, a momentary rate limit — are retried automatically with backoff (a few attempts, waiting longer between each).
- Permanent problems — a disconnected or expired account, no connected account for that platform, or a hard rate-limit — fail fast instead of burning retries on something that can't succeed until you fix it.
If the workers for a platform are down (or misconfigured) so that nothing is processing its queue, a post waiting on that queue fails within a few minutes rather than hanging indefinitely. You'll see it as failed and can retry once the platform is healthy again.
Manual publish actions
From a post's Detail Panel you have three manual controls:
| Action | What it does | Who |
|---|---|---|
| Publish Now | Skips the scheduled wait and publishes immediately. Eligible from draft, scheduled, or failed states (among others). | Anyone with schedule permission |
| Retry | Re-queues a failed publish (or one stuck publishing long enough to be considered orphaned). | Anyone with schedule permission |
| Mark as Published | Reconciles a post to Published without re-sending it — for when the content actually went live on the platform but the status didn't catch up (e.g. a publishing, failed, or partial post you've verified). | Owners and admins only |
It only corrects Buzzator's record to match reality. Use it after you've confirmed on the platform that the content is live — it won't post anything a second time.
Double-publish safety
The engine guards against publishing the same post twice. A claim is taken before the platform call, so a second attempt can't also publish — and a double-click on Publish Now is simply rejected (the post is already being published) rather than sending twice.
Rescheduling replaces the pending delivery: the in-flight wait is cancelled and a fresh one starts for the new time, so a post is never delivered on both the old and new schedules.
Related
- Posts Hub & the post lifecycle — where you find Publish Now, Retry, and Mark as Published, and every status a post moves through.
- Platform capabilities — what each connected platform supports.