Hi all — hoping someone has seen this before or can point me in a useful direction.
The symptom:
The Executions queue shows 10 items stuck in Queued / Starting soon for 53+
hours. The Workflows list won’t load at all and shows:
▎ Error fetching workflows
▎ Timeout waiting for lock SqliteWriteConnectionMutex to become available
Setup:
n8n Cloud instance
~13 active workflows, mostly Monday.com webhook-triggered
Stuck executions belong to two of them (an SEO writeup workflow + a script-generation workflow)
All 10 stuck executions started within seconds of each other — looks like a worker died mid-batch on May 1 around 21:46 UTC and never picked them back up
What I’ve already checked (via the public API):
Health check: OK (~400–700ms response)
Reads work fine — I can GET /executions/:id and see the records
Stuck records have status: “new”, startedAt: null, finished: false, totalNodes: 0 (i.e. they were accepted into the queue but never executed a single node)
I also see ~100 additional records from a separate workflow with status: “crashed”, finished: false, all with the exact same stoppedAt timestamp (2026-05-01T21:46:59.159Z) — looks like a recovery sweep marked them dead at once
Tried DELETE /executions/:id against the stuck records (both single-shot and in parallel) — every write attempt returns NO_RESPONSE / connection timeout. Reads continue to work normally. So the lock is specifically on the executions write path. Reads aren’t blocked, but no DELETE will land — which makes sense if there’s a long-held write transaction holding SqliteWriteConnectionMutex.
What I’m trying to figure out:
Has anyone resolved this without raising support? (I’ve already emailed help@n8n.io, but in case there’s a self-serve path I’m missing.)
Is there a known cause for a worker leaving zombie status: new records when it crashes mid-batch? Anything I can do on the workflow side to make this less likely (e.g. concurrency settings, batch sizing, idempotency gates)?
Once support clears the lock, is there a recommended way to bulk-purge the ~100 crashed/finished:false records via the API to keep the executions table from saturating again?
Happy to share more diagnostic detail (workflow IDs, execution IDs, timestamps) if it helps. Not in a rush for the stuck records themselves — they’re 53 hours stale and I don’t need their payloads — I just want the queue back so live work can run.
A) Did you try deleting or stopping the executions that glitched via the api? API reference | n8n Docs
B) Did you try unpublishing the workflow then analysing if execution queue statuses change/cancel then republishing? Not sure if it cancels pending or bugged executions but might be worth a try.
C) A nuclear solution to try in your case is copying the whole workflow to a new fresh one. If you are able to:
Unpublish the workflow with the queue glitch (prevents published webhook URLs colliding)
select + ctrl C all the nodes in the workflow
ctrl V in a new workflow → publish
I’d temporarily keep the old bugged one for safety.
Hey — thanks so much for jumping in, really appreciate the suggestions Quick status on each:
A) Tried it before posting. Hit NO_RESPONSE on every DELETE /executions/:id (single and parallel). Verified afterward — records were unchanged, the writes didn’t land.
B) Just tried this on your suggestion. Same result —POST /workflows/:id/deactivate returned NO_RESPONSE. Pulled the workflow back via GET afterward and confirmed it’s still active: true. Write didn’t go through.
C) I’m dead in the water here too, unfortunately:
-UI route (Ctrl+C / Ctrl+V): the Workflows list won’t load at all (SqliteWriteConnectionMutex timeout on every refresh), so I can’t open the workflow to even select the nodes.
-API route (POST /workflows): would hit the same write block we’re seeing on A and B. Reads are healthy across all endpoints (~400–700ms), but every write attempt times out.
So the picture is uglier than I first thought — it’s not just the executions table that’s locked, it’s any write to the DB. Reads sail through. That points at one stuck transaction holding the mutex against the whole write path, which only n8n’s backend team can clear (restart the worker / kill the transaction).
Already emailed help@n8n.io with the diagnosis. Sitting tight until they respond. Thanks again for the help — even though all three were blocked, ruling them out narrowed the picture a lot.
Will update the thread once support clears it in case anyone else hits this.
@Evan_Smoll those zombie status:new rows are the bull worker dropping its job lock mid-batch — support is the only way to clear the mutex on cloud, but once they do, run this scheduled purge so the executions table doesn’t saturate again:
swap your instance url + n8n api key header creds, deletes run sequentially so they won’t stack writes against the mutex again.
