Handling workflow execution timeouts and UI rendering lag during high-concurrency mobile multitasking

Hi everyone,

I’ve been using n8n for a while now to manage my automation workflows, and while it’s usually incredibly stable, I’ve hit a specific performance snag when monitoring my instance on devices that are under heavy system-wide load.

I’ve noticed that whenever my local environment is under significant resource pressure—specifically when I’m running several background executors or testing the arceus roblox environment for its multi-threading capabilities—the n8n editor UI becomes very “laggy.” More importantly, I’ve had several workflows fail with a “Node execution timeout” or a “Lost connection to the server” error during the execution of simple HTTP Request or Code nodes. It seems like the mobile browser or the host OS might be deprioritizing the n8n signaling thread when the CPU load hits a certain threshold, causing the heartbeat between the client and the server to drop.

While I was discussing these environmental bottlenecks with some other community members, we noticed that even the canvas rendering for large workflows starts to flicker or fail to load “Custom Content” blocks when the device is multitasking heavily in the background. Has anyone else noticed their instance becoming “unstable” or prone to silent execution failures if there are other high-performance tasks running on the same machine?

I’m trying to figure out if there’s a way to make the n8n UI more resilient—perhaps by adjusting the EXECUTIONS_TIMEOUT settings or if I should be looking into a more aggressive local caching strategy for the assets to ensure the editor stays responsive in “noisy” environments. If you’ve dealt with stabilizing the n8n experience while multitasking heavily—or have any tips on preventing these silent node failures during heavy background processing—I’d really value your input!

Thanks in advance for the help!

welcome to the n8n community @Josephine676
I’d first try to reproduce the same workflow from a stable desktop browser, with the host under normal load, and check whether the timeout still happens. Increasing EXECUTIONS_TIMEOUT can help with genuinely long-running executions, but it will not solve UI lag or dropped connections caused by CPU/RAM pressure or an overloaded browser. For reliable testing, I’d avoid using a heavily loaded mobile or multitasking environment as the baseline for workflow stability.

Can you confirm whether the workflow also times out when executed from a stable desktop browser while the n8n host is under normal CPU/RAM load?