Few things are more unsettling than watching a queue item sit under “processing” for far longer than any normal post should take, with no error, no progress, and no way to tell whether it’s still working or quietly dead. This used to be a real gap in the system. It’s fixed now, but understanding what caused it — and what the fix actually changed — helps you recognize the difference between a post that’s genuinely still working and one that’s stuck.
What Used to Happen
Content generation, especially for longer pillar pages or cluster posts, takes real time — sometimes long enough to bump up against the underlying job’s time limit. When that happened, the job would get killed mid-process. The trouble was in what happened next: because there was no handler for that specific failure case, the queue row never got updated. It just stayed marked “processing” — a status that, on its face, looks identical to “this is still actively working,” even though nothing was working on it anymore. There was no error message, no failed status, nothing distinguishing a post that was three seconds from finishing normally from one that had been abandoned mid-generation twenty minutes ago.
That ambiguity was the actual problem, more than the timeout itself. Timeouts on genuinely slow generations are going to happen sometimes; the real issue was that the system gave you no way to tell a timeout apart from normal progress.
What Changed
The fix adds explicit handling for exactly this failure case: when a job hits its time limit and gets killed, the stuck queue row now gets flipped automatically to a clear, terminal “failed” status, with a specific message noting that it timed out — rather than being left in limbo. Two details matter about how carefully this was built: it only touches rows that are still sitting in “processing” or “pending” (so it can’t accidentally overwrite a row that already resolved through a different path), and the failure gets logged as well, so there’s a record of it happening rather than a silent status flip with no trace.
How to Recognize the Difference Now
With the fix in place, “processing” should only ever be a brief, transient state — the normal duration of an actual generation. If you see an item sitting under “processing” for a stretch of time that’s clearly beyond how long generation normally takes on your site, one of two things is true: it genuinely is still working (long-form pillar pages with several cluster items can legitimately take a while), or it’s about to time out and will flip to “failed” shortly. Either way, you’re no longer stuck wondering — a “processing” item today will always eventually resolve to either “posted” or “failed,” it just may take a little while for the resolution to land if the underlying job is still within its time limit.
What to Do When You See "Failed" From a Timeout
- Check the failure message — a timeout-specific failure reads differently from a content or API error, and tells you the cause was duration, not a broken generation step.
- If it’s a large pillar-and-cluster batch, consider whether it’s genuinely too large for a single generation pass, or whether breaking it into smaller pieces would keep individual jobs comfortably under the time limit.
- Don’t just resubmit blindly — see “Restarting a Failed Post Without Duplicating Content” for how to retry cleanly without ending up with duplicate drafts or conflicting queue rows.
Why This Matters Beyond the Individual Post
A queue full of ambiguous “processing” rows doesn’t just hide the status of individual posts — it also undermines trust in the whole system, because you can’t tell at a glance whether your pipeline is healthy. This is one reason the Queue & Log and the Auto Scheduler’s live status widget are useful only if the statuses inside them are trustworthy. A “processing” that might actually mean “dead three hours ago” makes every other status suspect too. With the fix, every status in the log — waiting, posted, failed, needs-review — means exactly what it says, with no hidden fifth state masquerading as one of the others.
The Bigger Lesson: Time Limits Are a Fact of Life
Any system that generates substantial content on demand is going to have some kind of time limit on individual jobs — it’s a reasonable safeguard, not a shortcoming. “Monitoring Job Timeouts: The 300-Second Limit and What It Means” covers the specific limit in play and what tends to push generation close to it (typically longer pillar pages or clusters with many sections and images). The right posture isn’t to be surprised that timeouts exist; it’s to trust that when one happens, the system tells you clearly rather than leaving you to guess. That’s exactly what this fix delivers — not the elimination of timeouts, but the elimination of the silent, indefinite “processing” state that used to follow them.
