Every so often, a pillar or cluster article queued for generation doesn’t publish on schedule and doesn’t show up as a clean failure either — it just sits there, marked as processing, indefinitely. This is a specific, known failure mode with a specific cause, and understanding it makes the difference between a five-minute fix and hours of confused troubleshooting.
Why This Happens
Generation jobs — especially for long pillar pages or image-heavy cluster articles — run against a time limit. A job that runs long enough can hit that limit and get killed mid-process, which is a different failure mode than an ordinary error: because the job is terminated abruptly rather than failing through its normal error-handling path, the queue item it was working on can be left stuck showing “processing” or “pending” status forever, with no automatic cleanup marking it as failed. That’s the “sits in the queue and never resolves” symptom — the underlying job died, but nothing told the queue item it died.
What Fixed This
The underlying job now includes explicit handling for exactly this situation: if a generation job is killed by hitting its time limit, a stuck queue item left in a processing or pending state gets flipped to a clear, terminal failed status with an explicit timeout message, rather than being left in limbo indefinitely. Critically, this handling is careful not to touch a queue item that’s already resolved one way or another — so it only cleans up genuinely stuck items, not anything that completed normally in the meantime.
What to Do If You Find a Stuck Item
If you notice an item that’s been sitting in “processing” for an unusually long time — longer than any comparable article in the same batch took to complete — a few steps in order:
- Check how long it’s actually been stuck. A few minutes is normal variance; anything stretching well past your batch’s typical generation time per article is the signal worth acting on.
- Check the queue and log view for a corresponding failure message — if the automatic cleanup has already run, the item should show a clear timeout-related failure rather than an indefinite “processing” state.
- Re-queue the specific keyword once it’s confirmed failed, rather than the whole batch — there’s no need to re-run an entire 40-article cluster because one item stalled.
- Consider whether the stalled item shared a common trait with others that have stalled before — an especially long target length, both hero and per-H2 images enabled simultaneously, or a particularly demanding tone setting can all push an individual generation closer to its time limit.
Reducing How Often This Happens
A few practical adjustments lower the odds of hitting a generation timeout in the first place, particularly on large batches:
- Avoid stacking every heavy setting (long target length, hero image, per-H2 images, an elaborate tone) on every single article in a 40-post batch — reserve the full combination for your pillar page and a handful of flagship clusters, and use a lighter combination for the rest.
- Space out a large batch with an interval or one-per-day schedule rather than triggering every generation at once, since a burst of simultaneous heavy jobs is more likely to strain the same time limits than a steadily paced sequence.
- Watch for a pattern of repeated timeouts specifically on your longest or most image-heavy articles, and treat that as a signal to trim length or image density on future batches, not just a one-off glitch to re-queue past.
Making Sure the Background Scheduler Itself Is Healthy
A stuck generation job is a different problem from a scheduler that isn’t running at all, but they can look similar from the outside — both present as “this was supposed to publish and didn’t.” Confirm your scheduler’s heartbeat is current before assuming every unpublished item is a generation timeout specifically; if the scheduler itself has gapped, due items pile up for a completely different reason, covered in our companion piece on troubleshooting posts that sit in the queue past their schedule.
The Takeaway
A queue item stuck indefinitely on “processing” is a recognized failure mode, not a mysterious one — a generation job hit its time limit and was killed before it could report the failure normally. The fix is a clear terminal failure state instead of indefinite limbo, which means a stuck item today should resolve to an actionable failure message you can re-queue from, rather than something you have to track down manually. If you’re still seeing genuinely indefinite stuck items with no failure message at all, that’s worth flagging as its own issue rather than assuming it will resolve on its own.
