OpenTelemetry in n8n: tracing your executions in Grafana, Datadog or Jaeger

A webhook that answers in 4 seconds instead of 400 milliseconds: n8n's native execution panel shows clearly that something slowed down, but rarely where exactly the time went once several nodes chain together — an external HTTP call, a vector search, a language model, a Code node. Since version 2.19, n8n can export every workflow execution as OpenTelemetry traces: the open standard (a CNCF project) already used to observe the rest of an application stack. An n8n execution then becomes just another trace inside Jaeger, Grafana Tempo, Datadog, or any OTLP-compatible backend — no third-party agent, no timing hacks.

What OpenTelemetry traces inside n8n

The underlying idea revives the distributed tracing approach popularized by Benjamin H. Sigelman and coauthors in Dapper, a Large-Scale Distributed Systems Tracing Infrastructure (Google, 2010): reconstructing, from identifiers propagated across calls, the full path of a request through a system made of several steps. In n8n, each workflow execution becomes a root trace, and each executed node becomes a child span with its own start and end timestamp. A sub-workflow called through Execute Workflow shows up as a nested branch inside the same trace rather than an isolated execution you have to correlate by hand — exactly the kind of cross-component causality that Jonathan Mace, Ryan Roelke and Rodrigo Fonseca set out to automate in Pivot Tracing: Dynamic Causal Monitoring for Distributed Systems (SOSP 2015), instead of piecing it back together from scattered logs.

Concrete payoff: opening a slow trace in Jaeger immediately shows which of a workflow's five nodes ate 3.8 of the 4 seconds — an HTTP Request call to a third-party API, say — without reopening the run inside the n8n interface and comparing timestamps by hand.

Minimal configuration

Two environment variables are enough to get started:

N8N_OTEL_ENABLED=true
N8N_OTEL_EXPORTER_OTLP_ENDPOINT=http://your-collector:4318

n8n automatically appends /v1/traces to this URL and exports spans over OTLP/HTTP (Protobuf encoding) — point the variable at your collector's base URL, not at the /v1/traces path itself, a common mix-up on a first setup.

Three more variables round out this baseline depending on your deployment:

• N8N_OTEL_EXPORTER_OTLP_HEADERS: a comma-separated list of key=value pairs, for authentication when your backend (Datadog, Honeycomb, New Relic…) requires an API key in the export request's headers.
• N8N_OTEL_TRACES_SAMPLE_RATE: a ratio between 0 and 1 to sample traces on a high-volume instance instead of exporting everything — useful as soon as your daily execution count exceeds what your backend comfortably absorbs.
• The _FILE suffix on any variable above (for example N8N_OTEL_EXPORTER_OTLP_HEADERS_FILE) reads its value from a file instead of a plain-text variable — handy with a secrets manager on Docker or Kubernetes.

The queue mode trap: one setting per instance

On a single instance, these variables are enough after restarting the container. In queue mode, the configuration has to be repeated on every component — the main instance and all workers. A worker started without N8N_OTEL_ENABLED keeps executing the workflows assigned to it normally: nothing crashes, nothing alerts, but no trace is emitted for those runs. The typical symptom is instrumentation that looks like it works in testing (a single instance) followed by unexplained gaps in production the moment docker compose up --scale n8n-worker=3 spreads load across several processes. The safest check: set the N8N_OTEL_* variables at the level of the Docker Compose service shared by the main instance and the workers, rather than duplicating them service by service.

Picking a backend: Jaeger to start, Grafana Tempo or Datadog in production

Any OTLP-compatible collector works, but they don't all demand the same setup effort:

• Jaeger: a single Docker image (jaegertracing/all-in-one), a web UI included, zero configuration beyond exposing the OTLP port. The fastest way to confirm traces are actually arriving before wiring up a heavier backend.
• Grafana Tempo: fits natively into an existing Grafana stack, especially if you already expose your n8n instance's Prometheus metrics — both end up on the same dashboards.
• Datadog, Honeycomb, New Relic, Splunk: managed backends already running in many organizations; n8n then joins them as just another application service, instead of a separate log silo to watch on its own.

For a first local test, a minimal docker-compose.yml simply adds a Jaeger service next to n8n:

services:
  jaeger:
    image: jaegertracing/all-in-one:latest
    ports:
      - "16686:16686"   # web UI
      - "4318:4318"     # OTLP/HTTP collector

  n8n:
    image: n8nio/n8n
    environment:
      - N8N_OTEL_ENABLED=true
      - N8N_OTEL_EXPORTER_OTLP_ENDPOINT=http://jaeger:4318
    ports:
      - "5678:5678"

After a few workflow runs, the Jaeger UI at localhost:16686 already shows the traces, grouped by workflow name.

What OpenTelemetry doesn't replace

Three tools already covered on this blog sit at different layers of n8n instance observability, and combine rather than compete:

• Versus instance monitoring (/healthz, Prometheus metrics): the latter answers "is my instance up and healthy," an aggregated infrastructure question. OpenTelemetry answers "where did the time go on this specific execution," a point-in-time detail question.
• Versus Langfuse for AI Agents: Langfuse specifically traces calls to a language model (tokens, cost, reasoning) inside an AI Agent node. OpenTelemetry traces the mechanics of the entire workflow — useful even on workflows with no AI at all, like email triage or a stock sync.
• Versus the Error Workflow: that one catches failures to alert or retry. OpenTelemetry also catches executions that succeed but slow down — invisible to an Error Workflow that only fires on an explicit error.

Concrete use cases

• Diagnosing variable latency on the RAG Assistant Pack (€119): a chatbot that sometimes answers in 2 seconds and sometimes in 15 usually hides a bottleneck in either the vector search or the generation model call — a trace opened in Jaeger tells the two apart at a glance, instead of guessing from logs.
• Spotting an external provider slowing down a pipeline in the Inbox AI Pack (€79): if AI-based email triage keeps getting slower, a trace immediately distinguishes a drifting API call (IMAP provider, model API) from an issue inside the workflow itself.
• Documenting the performance of a pipeline in the Compliance & Audit Pack (€149): beyond the functional audit trail already stored in Supabase, traces let you show, if ever asked, that a case's processing stays within a predictable time window.

All three packs are bundled in the Complete FlowKit Bundle (€269 instead of €347 bought separately): the same OpenTelemetry instrumentation covers every workflow once it's enabled at the instance level.

In summary

Two environment variables are enough to make n8n emit standard OpenTelemetry traces, usable in Jaeger to get started or in a production backend like Grafana Tempo or Datadog. The feature is self-hosted only, available from the Community Edition onward, and needs extra care in queue mode where every worker must carry the same configuration. It replaces neither instance monitoring, nor Langfuse for AI Agents, nor the Error Workflow: it fills a specific blind spot — knowing where the time went inside one particular execution, a question neither an aggregated counter nor a failure alert can, by construction, answer.