On October 16, 2026, n8n released version 2.43.7 with an opt-in way to hand off unfinished automations during planned worker shutdowns. For teams maintaining business processes and background AI jobs on their own infrastructure, the benefit is preserving progress while restarting the process running the work.
This applies to queue mode, where separate worker processes execute workflows. An eligible workflow can finish its current step, save its progress and resume on another worker. The departing worker no longer has to finish the whole job, but the handoff happens between steps, not partway through one.
The practical choice is to evaluate it for background work that can tolerate a pause. Do not rely on it to keep a live conversation uninterrupted or to recover every run after an abrupt crash.
Which workflows qualify
The released eligibility rules draw a narrower boundary than “all production workflows”:
Eligible execution modes are webhook, trigger and retry, with execution state available. A webhook is an incoming request that starts a workflow; a trigger can include a schedule.
Manual editor runs and evaluation runs do not qualify. Neither do streaming or Model Context Protocol (MCP) executions, or any workflow containing an enabled Chat Trigger.
A run cannot be suspended while its caller still awaits a response or completion. A webhook run may qualify after its response is relayed, provided it meets the other conditions.
That makes scheduled background processing a candidate for evaluation, not an automatic guarantee. Check the actual trigger, response obligations and nodes—the individual steps in the workflow.
Check step duration, not just total runtime
The important timing question is how soon the current step can finish, leaving enough time to save progress and exit. n8n’s graceful-shutdown timeout defaults to 30 seconds and is configurable through N8N_GRACEFUL_SHUTDOWN_TIMEOUT.
Illustrative calculation, not a measured result: 20 sequential steps taking 10 seconds each total 200 seconds. If shutdown begins during one of those steps, the run could reach its next step boundary within 10 seconds. That leaves a theoretical 20 seconds in the default window for saving and exit work. This assumes an eligible run, functioning storage and sufficient overhead margin; it is not a reliability estimate.
By contrast, one step with 45 seconds still to run cannot fit into that same 30-second window. n8n describes suspension as opportunistic: a step that outlasts the allowance can still be forcibly terminated. A parent also waits for its Execute Workflow step to return before suspending, according to the feature’s scope notes.
For long, indivisible steps, retain a maintenance plan that lets them finish before shutdown. Turning on handoff does not make an ongoing model request or child workflow instantly transferable.
Expect a pause, not an instant switch
The WaitTracker implementation checks for waiting executions on a 60-second polling cycle and resumes them from stored execution data. That introduces a possible detection delay before the work is queued again; available worker capacity and queue delays also matter. Sixty seconds is not a guaranteed time to resume or finish.
Another worker needs capacity to take over, and the main process, Redis message queue and database must remain available. Those are part of n8n’s queue-mode architecture. A clean exit by one worker does not by itself establish uninterrupted service.
Queue mode is included in the free self-hosted Community edition, so this is relevant beyond enterprise deployments. Hosting and operations still cost money. Redundant main processes are a separate self-hosted Enterprise capability, not something worker handoff adds to Community.
Enable it deliberately, after a restart check
The 2.43.7 package is available on npm, but upgrading alone does not activate handoff. The worker setting defaults to false; explicit enablement uses N8N_WORKER_SUSPEND_EXECUTIONS_ON_SHUTDOWN=true.
Check main-instance compatibility as well as worker versions. The worker code treats missing caller-status information from an older main as an outstanding completion obligation, preventing suspension for those jobs. Package availability also does not establish n8n Cloud rollout or customer control of this setting.
Before enabling it in production, a useful staging check is to run a representative published workflow through its production trigger, with two workers and bounded test inputs. Request a normal shutdown of the worker running it. Then verify saved progress, completion on the receiving worker, the actual pause and downstream results. A manual editor run does not exercise the eligible path; n8n’s suggested restart procedure uses a production execution.
Include a flag-off comparison and an ineligible case, such as a run still owing a webhook response. For workflows that send messages or change external records, check for missing or duplicate effects rather than treating a “resumed” status as proof of business correctness.
Enable handoff when the representative runs qualify, finish their current steps within the shutdown allowance and resume within a delay your business accepts. Keep a separate restart plan for excluded workloads and steps that cannot finish in time.