How to Fix Clay Columns Stuck in Queued (2026 Guide)
A Clay column stuck on Queued is a confused run state, not an outage. Force-run it from the column header, which costs no extra credits, and know why a queued cell is a different problem from an empty one.
The column says Queued. It said Queued an hour ago. Nothing is running, nothing has failed, and there is no error to read. Just a column of cells waiting in a line that never moves.
A Clay column stuck on Queued is not usually a platform outage. It is a column whose run state got confused, and the fix is a specific button rather than patience. This guide covers what actually puts a column in that state, the order to unstick it, and why force-running the stuck rows does not cost you extra.
Why a Clay column sits in Queued
Queued means the cells were scheduled and the run never picked them up. That happens when the column's own state stopped matching what Clay thinks it should be doing, and there are three ordinary ways to get there.
| Cause | What you see | First move |
|---|---|---|
| The column was edited while it was running | Part of the column filled, the rest queued from a fixed point | Force-run the column |
| The run was stopped part way | A clean cut: everything before it done, everything after queued | Force-run the column |
| The column was changed several times | Scattered queued cells with no obvious pattern | Force-run, then duplicate the column if it persists |
| Front-end showing a stale state | Cells read Queued but the run already finished | Hard refresh before you touch anything else |
| Provider capacity on an AI column | Only the AI column queues, provider columns run fine | Check the rate limit on the key behind it |
The pattern worth learning is the shape of the queue. A contiguous block of queued cells starting at one row means the run was interrupted at that point. Scattered queued cells across the table mean the column definition changed underneath a run that was already going. Those two lead to the same first fix, but the second is more likely to need the duplicate-column fallback.
How to unstick the column
In order, stopping as soon as the cells move. Most columns clear on the first step.
Force-run the column
Click the column header, hover over Run column, and choose Force. This is the actual fix and most guides bury it: a normal re-run respects the state that is already confused, while Force resets it and pushes the queued cells through. Clay does not charge additional credits for force-running rows that were already stuck.
Hard refresh, then force again
Press Ctrl and Shift and R on Windows, or Cmd and Shift and R on Mac. The front end polls for column status, and a stale page can show Queued for cells that already completed. Refresh first, and if they still read Queued afterwards, force-run once more against a clean page state.
Duplicate the column onto the stuck rows
If force-running twice changes nothing, the column state is beyond resetting. Duplicate the column, filter the table for the rows still queued, and run the copy on that filtered view. Then merge the two columns back into one. This is the fallback, not the opening move, because it costs you a rebuild that force-running usually avoids.
Check the provider behind an AI column
If only your AI column queues while everything else runs, the bottleneck is throughput on the model behind it rather than Clay. GPT columns want a meaningful tokens-per-minute allowance to run reliably at volume, and a tight rate limit shows up as a queue that drains slowly or not at all. Check the limit on the key before you blame the column.
Keep it from happening again
Every recurring queue problem traces back to editing a column while it was working. Four habits remove most of them.
- Let a run finish before you change the column. Editing a definition mid-run is the single most reliable way to produce a queue, and the change usually could have waited four minutes.
- Make changes on a duplicate. If you want to try a different prompt or provider, duplicate the column and edit the copy. The original keeps running and you keep a working version.
- Refresh at the start of a session. A page left open overnight polls against a state that has moved on, and half the queues people report are the front end rather than the run.
- Watch throughput on AI columns. A rate limit does not announce itself, it just looks like a slow queue. If a column consistently drains at a crawl, look at the allowance on the key before you look at Clay.
None of this is exotic. It is the same discipline you would apply to any long-running job you can edit while it runs, and a Clay column is exactly that.
If your cells are coming back blank rather than queued, that is a different failure with different causes. We covered it in why Clay AI enrichments return zero results.
Why ReactIn has no queue to unstick
The reason a Clay column queues is that work is batched: you define a column, point it at a few thousand rows, and a job runs across all of them. Any interruption to that job leaves a visible line of unprocessed cells.
ReactIn does not batch. Leads arrive one at a time as signals fire, and each one is processed on its own on our servers. There is no bulk job to interrupt, so there is no queue that can freeze part way and no column state to reset. A lead that fails is retried on its own rather than blocking the ones behind it.
The practical difference shows up when something does go wrong. A stalled Clay column holds everything downstream of it: the scoring, the conditional path, the export. In ReactIn a single lead having a bad moment does not stop the campaign, because there was never a batch for it to sit in.
The honest trade: this is not a replacement for a data workbench. Clay does things ReactIn does not attempt, and if your job is running arbitrary enrichment across arbitrary tables then a column model is the right shape and queues are its cost. The comparison only holds for the specific job of turning LinkedIn intent into outreach.
The mechanics of a list that fills itself lead by lead are covered in our guide to intent-based marketing automations.
A stuck column is a two-minute problem once you know which button resets the state. It only becomes an afternoon when you start rebuilding the table.
Frequently Asked Questions
Sources & Further Reading
- Clay's community support covers resolving cells stuck on queued status with the force-run steps.
- For a column that never starts on its own, see how to fix a column not running automatically.
- The AI-specific case is documented in Clay's guide to GPT columns stuck in queued status.
Related Articles
How to Fix Expandi Messages Not Sending (Pending Invites)
A connector campaign opens with a connection request, and a lead who already has one pending cannot receive a second. So the campaign has nothing it is allowed to do, and it says so in a tab most people never open.
How to Fix Phantombuster "Error During Loading of Chat Widget"
Phantombuster documents this one, and the documented fix is mostly to wait. The expensive part is a Phantom left looping against it, burning execution time on attempts that cannot succeed.
Working Around the Limitations on Salesflow (2026 Guide)
CSV import exists, so does a campaign type for contacts you already hold, and so do shared blacklists. The constraints that actually bite are narrower: rejected Sales Navigator URLs, per-route caps, and a deliberate block on duplicates.
How to Fix Dripify Lead Collection Stalls (2026 Guide)
Most stalled collections have finished or are waiting. The Lead Collection Report names the cause, the search cap ends runs silently, and working hours suspend lead loading as well as sending.