We use n8n cloud. While working a any workflow (editing or running), we’re often seeing the UI “hang”, with the following error message popping up after ~30 seconds:
Timeout waiting for lock SqliteWriteConnectionMutex to become available.
It feels like this may be related to resource availability, which in a way may be considered normal on a cloud-based tool, but the error has become so frequent lately that it is starting to impact our workflow.
What is the error message (if any)?
Problem running workflow
Timeout waiting for lock SqliteWriteConnectionMutex to become available
In other cases, the following error message may appear instead:
Request failed with status code 502
Please share your workflow
N/A - happens with all workflows, all authors/users.
Hello @mohamed3nan! Thank for for sharing your findings.
I think we haven’t actively imported workflows in a while, but nonetheless we’ve performed the upgrade to the most recent version. Always a good idea, I guess! For now, we haven’t noticed this issue anymore, so fingers crossed that effectively something was done to remediate this.
+1 on this issue. We also frequently run into “Timeout waiting for lock SqliteWriteConnectionMutex to become available” errors.
We ping every hour with the number of flows that are running at that moment and we are well below the 20 maximum concurrent executions. This error is now the biggest reasons we run into errors. Any insights into what causes it, and what we can do to prevent the error is much appreciated.
Cloud hosted
I looked at some of the recent errors, and it appears to happen particularly in/around “execute workflow” nodes. Do any of the other people experiencing this issue see the same pattern?
This error on n8n cloud is worth unpacking a bit because it’s counterintuitive — you’d expect cloud to abstract away database issues, but what’s happening here is that even cloud instances use SQLite internally for certain operations (primarily execution logging and queue management), and under concurrent write pressure the write mutex can time out.
The ‘well below 20 concurrent executions’ observation from @Jaco_Ruizendaal is important context. The bottleneck isn’t necessarily the number of active executions — it’s write frequency. If you have workflows that write frequently to the execution log (especially ones with lots of sub-nodes, loops, or high-frequency triggers like every minute), each of those generates multiple write operations. 10 workflows each doing 50 node executions will hammer the write queue far harder than 20 simple workflows. The mutex error happens when writes queue up faster than they can complete.
Practical things that can help reduce this on n8n cloud: First, check if any of your workflows have extremely high-frequency triggers (every 1 minute or less) — bumping those to every 5-10 minutes often makes a meaningful difference. Second, reduce the execution data retention if possible. If you’re keeping full execution data for all workflows indefinitely, that’s a lot of write I/O. Third, if you have workflows that loop thousands of times, splitting those into batches with a Wait node between batches gives the write queue time to flush.
If the issue persists and you’re on a paid cloud plan, it’s worth opening a support ticket — the n8n team can look at your instance’s actual write throughput and may be able to adjust your instance’s resources. The 502/503 errors you’re seeing after the mutex errors are the instance recovering from being overloaded, which is a separate symptom of the same underlying pressure.
Hello @OMGItsDerek! That is extremely useful feedback.
While me and my colleagues aren’t new to n8n, we are new as far as understanding the infrastructure and inner workings are concerned. So, thanks for the insights on that.
You’ve provided a few very actionable tips and these make perfect sense, so we’ll go and review our workflows with that context in mind. I’ll hopefully remember to post an update here on how that works out…
