Every post that passes through the scheduling system — whether you queued it manually, the Auto Scheduler placed it, or a workflow chained it into a sequence — ends up in the Queue & Log with exactly one of four statuses at any given moment. Understanding what each one actually means, and more importantly what it requires of you, is the difference between glancing at the log with confidence and squinting at it wondering if something’s wrong.
Waiting
Waiting means scheduled but not yet due — the item has a target time attached, and the every-minute scheduler check hasn’t reached that time yet. This is the default, expected state for anything you’ve scheduled for later, and it requires nothing from you. It only becomes worth investigating if an item is still sitting in “waiting” well past the time it was supposed to publish, which usually points to the scheduler tick itself not running rather than a problem with the specific item (see “How to Verify Your Scheduler Is Actually Running (Heartbeat Checks)”).
Posted
Posted means published successfully — the content is live on your site. This is the terminal, everything-worked state, and there’s nothing further required. Posted items are the ones the Content Calendar links directly to the live page when you click their chip, and they’re what “Add to Queue → ASAP” produces immediately, since ASAP publishing skips the waiting state entirely and goes straight to posted (or straight to failed, if something goes wrong in the process).
Failed
Failed means something went wrong, and it needs a decision from you. Failures can come from a handful of causes — a content generation error, a publishing issue on the destination site, or a job that ran long enough to hit its time limit and got killed mid-process. That last case used to be a real gap: timed-out jobs would leave a queue row stuck showing “processing” indefinitely with no clear resolution. That’s fixed — a handler now catches exactly this case and flips the stuck row to a clear “failed” status with a specific timeout message, rather than leaving it ambiguous (full detail in “Diagnosing a Post That’s Stuck in ‘Processing’ Forever”). Whatever the specific cause, “failed” always means: look at this, understand why, and decide whether to retry.
Needs-Review
Needs-review is different from failed in an important way: it isn’t an error. It’s a deliberate pause point where the system wants a human decision before something proceeds further, rather than either publishing automatically or treating the situation as broken. Content that’s flagged this way sits waiting for your judgment call, not a fix — the distinction matters because “failed” implies something to repair, while “needs-review” implies something to approve, reject, or edit.
Reading the Four Together
Think of the four statuses as sitting along a simple path: everything starts as waiting (or skips straight through if it’s an ASAP publish), and eventually resolves into one of three outcomes — posted (the good outcome), failed (something broke and needs attention), or needs-review (nothing broke, but a decision is needed). A healthy queue, glanced at broadly, should show mostly waiting and posted items, with failed and needs-review appearing occasionally rather than piling up. A queue where failed or needs-review items are accumulating faster than they’re being resolved is the clearest sign something upstream — a generation setting, a workflow’s pacing, or the scheduler’s own health — needs attention.
Where You'll Encounter These Statuses
- The Queue & Log itself — the full, authoritative list of every item and its current status.
- The Content Calendar — the same statuses represented as chips on the relevant date, with posted chips linking to the live post and failed/needs-review chips linking back into the highlighted Queue & Log row.
- The Auto Scheduler’s live status widget — a recent-activity feed that now links through for both waiting and posted items, not just posted ones (see “Reading Auto Scheduler’s Live Status Widget Correctly”).
All three views are reading from the same underlying statuses — there’s no separate “calendar status” or “widget status” that could disagree with the Queue & Log. If a chip shows failed on the calendar, the Queue & Log will show the identical failed row with the identical reason.
What to Actually Do With Each Status
- Waiting: nothing, unless it’s overdue — then check scheduler health.
- Posted: nothing — optionally spot-check the live page via the calendar’s clickable chip.
- Failed: read the failure reason, decide whether to retry (see “Restarting a Failed Post Without Duplicating Content”), and if failures cluster around timeouts, consider whether your content is simply too large for a single generation pass.
- Needs-review: make the judgment call the flag is asking for — approve, adjust, or reject — rather than leaving it parked indefinitely.
Four statuses, four clear meanings, and — critically — no fifth, ambiguous state hiding among them anymore. That predictability is what makes it possible to trust a glance at the queue instead of needing to dig into every item individually to figure out what’s actually going on.
