On November 9, 2026, n8n released version 2.46.7 to address a failure that can leave business automations caught in repeated service crashes. The update brings recovery-attempt limits to the 2.46 branch for deployments where reloading a saved workflow run exhausts available memory.
The fix was already included in the November 3 pre-release, 2.47.0. This update brings the same protection to teams staying on 2.46, including those using n8n to connect AI models and tools.
Why restarting can repeat the failure
According to the maintainers’ explanation, a paused run—or one left queued after shutdown—can retain more saved data than the service can load into memory. Loading happens before its status changes to running. If that load kills the process, the run remains eligible for recovery, so restarting can trigger the same failure again.
The maintainers attribute 22 of 37 crash loops escalated to support since August to this cause. That is their support sample, not a measure of how many n8n customers are affected or how many outages the patch will prevent.
A running service is not a completed workflow
The released configuration defaults to two recovery loads per execution—an execution is one run of a workflow. Each attempt is recorded in the database before loading begins, so a load that kills the process remains counted. Once its allowance is exhausted, n8n stops loading that run and marks it as crashed.
Administrators can configure the allowance through N8N_EXECUTIONS_MAX_RESUME_ATTEMPTS. Setting it to zero removes the limit. The count resets once the execution runs; this is not a lifetime cap of two workflow runs.
The practical implication is that service recovery and task completion need separate checks. An available dashboard does not prove that the interrupted work finished. Because the counter belongs to each execution, two attempts also does not mean an entire installation is guaranteed to recover within two restarts.
There is a deployment boundary, too: the startup recovery change for queued runs applies to regular mode, where work runs in-process. Queue mode uses separate workers and a different queued-run recovery path. This is not a blanket fix for every queue-mode outage or memory failure.
What operators should check
For affected self-hosted 2.46 deployments, evaluate the 2.46.7 update. Follow n8n’s installation-specific update guidance, which recommends reviewing release notes and testing the update outside production first. The earlier inclusion in 2.47.0 means users already on that version do not need to downgrade for this fix.
For n8n Cloud, the instance owner should check the versions offered in Instance settings → Updates. The public release does not establish that 2.46.7 is selectable for every account. n8n documents one to two minutes of unavailability when a version change restarts the instance.
After recovery, inspect the affected run and its expected business result before deciding whether to rerun it. The cap does not make oversized data fit in memory. n8n’s memory guidance recommends smaller batches, sub-workflows that return limited data, or more available memory. Those address the workload that caused the failure.
For the different problem of preserving progress during planned maintenance, see when n8n can hand off workflows during worker restarts.