n8n 2.43.8 Turns Off expression.evaluate Spans by Default

If your OpenTelemetry dashboards stopped showing expression.evaluate spans after upgrading n8n, the likely reason is a deliberate default change, not a monitoring failure. n8n 2.43.8, released on October 19, 2026, flips N8N_EXPRESSION_ENGINE_TRACES_ENABLED from true to false. According to n8n, workflow, node and agent spans don't change, and expression metrics keep flowing. For a business running automations in production, that means no alert needs rewiring and nothing is wrong with your workflows. What you should do is confirm that the visibility you actually rely on is still there before anyone "fixes" a setting that isn't broken.

What changed in 2.43.8

The stable release notes list a single core fix: "Turn off expression spans by default (#41310)". The linked pull request says it plainly: n8n no longer creates expression.evaluate spans by default, and setting the variable to true brings them back. It also states that N8N_EXPRESSION_ENGINE_OBSERVABILITY_ENABLED stays true, so expression metrics are unaffected.

We didn't take the PR description on faith. The configuration file at the [email protected] release tag shows the environment variable N8N_EXPRESSION_ENGINE_TRACES_ENABLED bound to tracesEnabled with a default of false, sitting next to observabilityEnabled with a default of true. The code and the narrative agree.

Why the change? n8n's explanation is short: one customer's endpoint was flooded with these spans. That's the vendor's account of a single case, and it doesn't tell you how common the problem is or what it cost. It does make sense mechanically, though. An expression span is created per evaluation, and a busy workflow can evaluate a lot of expressions per execution. Workflow and node spans scale with runs and steps. Expression spans scale with every templated field inside them.

What this does not mean

It's a telemetry default, nothing more. It doesn't stop workflows from executing, it doesn't disable observability as a whole, and it isn't a security fix. Spans from unrelated libraries aren't part of this change. It also has nothing to do with the credential-test failures we covered in an earlier post, so don't expect this patch to resolve those. And whether you see a difference at all depends on your setup: if you never enabled OpenTelemetry, or you already set the variable explicitly, your traces won't look any different.

Checks to run before changing any settings

These steps follow the test outline in n8n's pull request. We haven't reproduced them on a local install, so treat them as a sensible verification plan rather than published results. Prerequisites: a self-hosted n8n deployment with OpenTelemetry export already configured, access to its environment variables, and a non-production environment you can upgrade first.

1. Inventory what's deployed: the current n8n version, the expression engine in use, your OpenTelemetry exporter settings and any explicit environment overrides. Look specifically for N8N_EXPRESSION_ENGINE_TRACES_ENABLED and N8N_EXPRESSION_ENGINE_OBSERVABILITY_ENABLED in your compose files, Helm values or secrets manager.
2. If N8N_EXPRESSION_ENGINE_TRACES_ENABLED is already set to true, the new default won't apply to you. Decide whether you still want those spans before upgrading.
3. Upgrade a non-production instance to n8n 2.43.8 and point it at your existing OTLP collector or a local one.
4. Run a representative workflow that uses expressions, ideally one that mirrors a real production job.
5. In your tracing backend, confirm the workflow and node spans are present and look the way they did before the upgrade.
6. Confirm that expression.evaluate spans are absent under the default settings, and that expression metrics are still being recorded.
7. Only if you deliberately need expression-level debugging, set N8N_EXPRESSION_ENGINE_TRACES_ENABLED=true, restart, and rerun the workflow. Check that slow or erroring evaluations show up as spans, and watch span volume and load on your collector while it's on.
8. Once the results match, roll 2.43.8 to production and update any dashboard or alert that counted expression.evaluate spans, so a quiet panel isn't mistaken for an outage.

Should you turn expression traces back on?

For most teams, probably not as a permanent setting. Workflow and node spans already tell you which run failed and which step was slow. Expression spans earn their keep when you're chasing a specific problem inside a node, like a template that's slow or a field that intermittently throws. Turn them on for that investigation, keep an eye on collector volume, and turn them off again when you're done. That's a cleaner habit than paying, in storage and noise, for detail nobody reads.

The quieter default is the right call for production. The work on your side is small: one environment check, one test run and a dashboard tweak, done before someone spots the missing spans and files a ticket.