n8n now supports OpenTelemetry natively, allowing every workflow execution to be emitted as a trace, so n8n shows up inside the same observability stack your team already uses for the rest of production.
There is no sidecar to run and no patching to maintain, and because everything is built on the OTLP standard, there is no vendor lock-in either. Point n8n at any OTLP-compatible collector or backend, whether that is Jaeger, Tempo, Datadog, Honeycomb, New Relic, or Grafana Cloud, and you start seeing what your workflows actually do at runtime.
Why this matters
Workflows have become production systems. They process payments, route support tickets, sync CRM data, drive AI agents, and keep internal operations moving. So when something goes wrong inside one of them, the questions are the same ones you would ask of any other service. Which step failed, how long did it take, what did it call, and what came back?
Until now, answering those questions in n8n meant living inside the execution view. That is fine for one workflow on a single instance, but it tends to fall apart in the situations that matter most. Picture a webhook from your application hitting n8n, n8n calling three downstream services, one of those services running slow, and the support engineer on call sitting in Datadog with no idea that n8n is even in the path.
With OpenTelemetry support, n8n becomes a first-class participant in distributed tracing. Each workflow execution produces a root span that carries status, duration, and error information, and you can turn on an optional child span for every node so it is easy to see which step is slow or failing.
What you can do with it
Consider an on-call engineer at a fintech that uses n8n to orchestrate payment reconciliation. A customer reports that a refund took twenty minutes to land. In Datadog, the engineer pulls up the trace for that refund request and sees the full path, from the API gateway to the payments service, into the n8n workflow that fans out to a fraud check, the ledger, and a notification step, and on to the downstream banking API. The slow span is right there, a third-party fraud-check call that timed out and retried twice. The engineer knows exactly which node, in which workflow, on which instance, and with which inputs, with no log grepping and no guesswork.
Or take a platform team rolling out a new AI agent built in n8n. The agent calls an LLM, hits an internal search API, writes back to a database, and posts an update to Slack. Before OTel, the team could see the run inside n8n and the LLM call inside their AI provider's dashboard, but stitching the two together was a manual job. With OTel enabled, the whole thing becomes one connected trace, sampled and stored in the same backend as the rest of their services.
And for a team running n8n in queue mode across multiple workers, traces from those workers correctly parent back to the main process. As long as the same OTel environment variables are set on every instance, the picture stays coherent.
How it works
n8n emits spans over OTLP HTTP using Protobuf encoding, so anything that speaks OTLP can receive them. The piece that makes this genuinely end-to-end, rather than just internal to n8n, is trace context propagation.
On the inbound side, if a webhook request to n8n includes a traceparent header, the workflow execution span is created as a child of that trace, so the system that called n8n keeps a continuous view of the request. On the outbound side, HTTP Request nodes can inject traceparent into outgoing calls so downstream services continue the trace under the same trace ID. Spans from sub-workflows are parented to the calling workflow's span, which preserves the call hierarchy, and when a workflow resumes after a wait, the new span uses a span link to point back to the previous one, so long-running orchestrations stay traceable across pauses. This is the part that turns tracing from a debugging convenience into something an SRE team will actually rely on.
Get started
The minimal configuration is two environment variables set on each n8n instance you want workflow tracing enabled:
export N8N_OTEL_ENABLED=true
export N8N_OTEL_EXPORTER_OTLP_ENDPOINT=http://<your-collector-host>:4318
The full configuration reference and a local Jaeger walkthrough are in the OpenTelemetry docs.
What's next
This release covers workflow execution tracing, which is the foundation, and there is more already in flight. We are working on deeper agent traces, with richer spans inside AI agent nodes for LLM calls, tool calls, and evaluation steps, so that trace and eval platforms get the signal they need. We are building application tracing that will surface traces from inside n8n itself, including database queries, API endpoint timing, and internal errors. And we plan to add instance metrics, so operational signals like queue depth, active workflows, and resource gauges can be exported the same way.
The direction is consistent throughout. Any signal an operator or developer would expect from a production service should be emitted through open standards, into the backend of your choice.