n8n 2.34.4 - Task Runner Health Check Fixes


n8n [email protected] was published on August 7, 2026. The main operator facing change fixes a failing task runner health check, while a second core fix handles display option dependencies that fall outside their current scope. The release is a regular patch, not a prerelease.

The full release notes and downloads are on the GitHub release page.

The first change addresses a task runner health check that could fail. The release notes tie the correction to issue 35816 and commit badd50e. They do not identify a particular deployment topology, task type, or configuration key, so the safe reading is narrow: this patch repairs the check itself.

That still matters in production. Health results often feed readiness decisions, dashboards, and alert routing. A failing check can create noise or make a runner look unavailable even when the useful diagnostic question is whether task execution is also affected. The notes do not claim a throughput gain, lower latency, or a task execution fix, so none should be inferred from this patch.

After rollout, exercise the same health check path used by the deployed runner topology. Compare the result with task execution and runner logs. This separates a repaired health signal from unrelated queue, worker, or workflow failures that the release does not address.

The second change updates core handling for display option dependencies that are outside the current scope. It is tracked in issue 35863 and commit 1e9734d. This is a configuration metadata correctness fix rather than a new workflow feature.

Conditional display rules affect which options are relevant in a given context. When a dependency points beyond that context, core now has explicit handling for the case. The release notes do not name affected nodes, credential types, workflow fields, or editor paths. Teams should therefore avoid assuming that every conditional parameter issue is covered.

For data pipeline owners, a focused regression check is more useful than a broad workflow replay. Open or import representative workflows that contain conditional node options, change the controlling values, and confirm that dependent options behave as expected. Pay particular attention to internal nodes or custom integrations with dense parameter trees. No workflow schema migration or stored data rewrite is listed.

This release contains two bug fixes, both labeled as core changes. There are no documented breaking changes, migration steps, new command line flags, or configuration keys. The release metadata also marks [email protected] as a normal release rather than an alpha, beta, or release candidate.

That makes the validation surface small. Check runner health reporting first, then test conditional display behavior in a representative set of workflows. Existing task success rates, queue depth, and runner logs remain useful controls during a staged rollout, but the notes provide no evidence for changing capacity settings or retry policy.

Operators who need the exact patch references can use the GitHub release page as the source of record. Its narrow scope is useful here: the release fixes two known core defects and makes no broader compatibility claim.