A post that’s supposed to have published an hour ago and is still sitting in the queue is one of the more unsettling things to notice on a content dashboard, mostly because the cause could be anything from a harmless processing delay to a job that’s actually stuck and needs intervention.
The First Question: Processing or Genuinely Stuck
Posts in the queue past their scheduled time fall into two categories that look identical at a glance but need different responses: still legitimately processing (waiting for its turn behind other queued work, or mid-generation on a longer post) versus actually stuck (a failed job that never properly errored out, just silently stopped progressing). The Queue & Log view’s status field is the first place to check which one you’re looking at.
Reading the Queue Status Correctly
A post still shown as “waiting” or “processing” well past its scheduled time isn’t necessarily broken — if the scheduler is working through a backlog of other posts ahead of it, the actual publish time can slip behind the originally scheduled time without anything being wrong. A post shown as “failed” or one that’s been sitting in an unchanged state for far longer than a normal generation-and-publish cycle takes is the stronger signal something needs attention.
Common Causes of a Genuinely Stuck Post
The most frequent real causes are a rate-limited external API call during generation that never properly retried, a scheduler process that stopped running without restarting (a heartbeat check catches this), or a job that hit the processing timeout mid-generation and didn’t get correctly re-queued for the next run.
Checking Whether the Scheduler Itself Is Running
Before troubleshooting an individual stuck post, confirming the scheduler process is actually running at all is worth the thirty seconds it takes — a single stuck post in an otherwise healthy queue is a different problem than an entire backlog building up because the scheduler process silently stopped. The scheduler’s own heartbeat status answers this quickly.
Manually Restarting a Stuck Post
For a post confirmed stuck rather than merely delayed, restarting it — rather than deleting and recreating it from scratch — is the safer first move, since a proper restart resumes from the queue rather than risking duplicate content if the original generation actually completed but just failed to publish.
When to Escalate Beyond a Simple Restart
A post that gets stuck repeatedly on restart, rather than a one-off stall, usually points to a problem with the specific job itself — a malformed keyword, a content brief triggering a generation error, or a genuinely broken external API dependency — rather than a transient scheduler hiccup, and is worth investigating at that level instead of restarting indefinitely.
Preventing Recurrence With Monitoring
Sites publishing at real volume benefit from proactively monitoring queue health — flagging any post that’s exceeded a reasonable processing window — rather than discovering stuck posts only when someone happens to check the dashboard. This is the same underlying signal a heartbeat alert on the scheduler itself provides, applied at the level of individual jobs instead of the whole process.
Where to Go Next
For the complete pillar and cluster scheduling workflow this queue sits inside, see the complete guide to pillar pages and topic clusters.
