n8n AI Agent Observability: What It Actually Did

If you're running AI agents in n8n and something goes wrong, execution logs won't save you. They show that a run finished; they don't show what the agent decided. Real observability for an n8n AI agent needs three layers: n8n's own OpenTelemetry traces for timing and failures, an LLM tracing layer like Langfuse for the prompts and tool calls, and a cost record stamped with a client identifier so you can attribute spend. n8n ships the first layer natively as of version 2.15.0. The other two you build. Here's how we run it across the client agents we maintain.

Execution monitoring and observability are not the same alarm

We've written before about n8n workflows that fail silently — the ones that stop firing and nobody notices for two weeks. That's a monitoring problem, and an error workflow fixes it.

AI agents introduced a second failure mode that error monitoring can't see at all: the run that succeeds while being wrong.

An agent picks the wrong tool. It invents a CRM field name that doesn't exist and the API accepts it as a no-op. It summarises the wrong email thread. It burns forty thousand tokens looping between two tools before giving up and answering anyway. Every one of those executions comes back green. Your error alerts stay quiet. You find out when the client emails you.

That's the gap observability fills. Monitoring asks did it run? Observability asks what did it decide, and what did that cost?

What n8n gives you natively in 2026

n8n closed a real chunk of this gap this year, and a lot of the advice floating around predates it.

As of n8n 2.15.0 (30 March 2026), n8n emits OpenTelemetry traces for workflow executions. You set two environment variables:

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

and every run lands in whatever OTLP backend you already use — Jaeger, Grafana Tempo, Datadog, Honeycomb, New Relic. No sidecar, no custom exporter, no timing hacks in a Code node. If you already have observability for the rest of your infrastructure, n8n now sits inside it.

Two other things shipped worth knowing. n8n 2.17.0 (13 April 2026) added an insights summary endpoint at GET /api/v1/insights/summary, and 2.20.0 (5 May 2026) let self-hosted instances retain insights data for up to 365 days by default via N8N_INSIGHTS_MAX_AGE_DAYS.

The catch: the insights endpoint needs an API key with the insights:read scope and an Enterprise licence, and log streaming to external systems is a paid feature too. If you're on the self-hosted community edition — which is where most agencies we talk to are, and where self-hosted usually beats cloud for agency margins — you don't get either. The OTLP export is the layer that works for you, which is why we build around it instead of around n8n's own reporting.

The three questions the stack has to answer

Before picking tools, decide what you actually need to answer at 9am when a client calls. For us it's three things, in this order:

1. What did the agent do on run X? Not "the workflow succeeded" — the actual sequence. Which tools it called, in what order, with what arguments, and what came back. If you can't replay a specific run, you can't debug an agent.

2. Is this run normal? Cost per run, tool-call count and latency all need a baseline. Drift is the early warning. An agent that suddenly makes nine tool calls where it used to make three is telling you the prompt broke, the data changed, or someone edited a tool description.

3. Who pays for it? Every token has an owner. If you can't split spend by client, you're carrying a variable cost against a fixed retainer and guessing at your margin.

n8n's OTel traces answer the first question partially and the second one loosely. They don't answer the third at all.

Layer two: tracing what the model actually did

OpenTelemetry gives you the shape of the run. The LLM layer gives you the content — prompt, completion, tool arguments, token counts, model name, latency per call.

Langfuse is what we reach for, self-hosted next to n8n. A few practical notes people get wrong:

• The official Langfuse n8n community node (@langfuse/n8n-nodes-langfuse) is prompt management, not tracing. It fetches prompts from your Langfuse project into a workflow. Useful — centralising prompts beats editing them inside twenty nodes — but installing it does not give you traces. Wire tracing separately over OTLP or a community tracing node.
• Trace at the tool boundary, not just the agent boundary. One span per agent run tells you it took eleven seconds. Spans per tool call tell you that nine of those seconds were one slow HTTP node the agent kept retrying.
• Store the input. The single most useful field when a client disputes an output is the exact text the model received, including whatever the retrieval step injected. Half of "the AI hallucinated" turns out to be "the retrieval step returned the wrong document."

Sampling is fine once volume grows, but keep 100% of failed and human-rejected runs. Those are the ones you'll want to read.

Layer three: cost attribution per client

This is the layer nobody writes about, and it's the one that matters most if you run agents for clients rather than for yourself.

The fix is unglamorous. Make a Set node the first step in every client-facing agent workflow and stamp the run:

clientId:    acme-hvac
environment: production
agent:       inbound-lead-qualifier

Carry those fields through the workflow so they attach to every LLM call and land on the trace as tags. Then compute cost per run — input tokens times the model's published input rate, plus output tokens times the output rate — and write it to a Data Table or a sheet alongside the identifier.

The arithmetic matters more than people expect. A qualifier agent averaging 6,000 input and 700 output tokens per lead looks trivial per run. At 40 leads a day across eight clients, that's roughly 1.6 million input tokens a day, and the model you picked in the build phase quietly decides whether that's a rounding error or a line item you have to explain. We covered the model-choice side of that in our notes on cutting Claude API costs without wrecking output quality.

Without the client identifier you get one aggregate invoice and a conversation you can't win. With it, you can point at an account, show what it consumed, and either raise the retainer or fix the prompt. We've done both.

Alert on drift, not just on red

Once you have traces, resist the urge to alert on everything. Our production rule set is short:

• Failed executions — the standard error workflow, unchanged.
• Cost per run above 3× its trailing baseline — usually a retry loop or a runaway context window.
• Tool-call count outside its normal band — an agent that stops calling a tool is as broken as one that calls it constantly.
• Human rejections on approved tool calls — n8n 2.6.0 (26 January 2026) added human-in-the-loop approval on individual AI tool calls. If a human is denying an agent's proposed action repeatedly, the agent is wrong and the prompt needs work.

Everything else goes in a weekly review instead of a page. Alert fatigue kills observability faster than having no observability, because a team that ignores twelve alerts a day will ignore the thirteenth one that mattered.

And none of this replaces testing before you ship — it catches what testing missed. We keep a separate pre-production gate for that, covered in how we test n8n AI agents before production.

Own the data, rent the dashboard

One strategic note, because 2026 made it concrete.

LLM observability consolidated fast this year. ClickHouse acquired Langfuse in January. Mintlify acquired Helicone in March and moved it to maintenance mode — security patches and new model support, no new features. Cisco picked up Galileo shortly after. The standalone category is being absorbed into bigger infrastructure stacks.

We're still recommending Langfuse. But the reason we're comfortable doing it is that our instrumentation is OpenTelemetry, we run our own collector, and the traces land in storage we control. If the dashboard changes hands again, we change a config value. Agencies that instrumented directly against a vendor SDK are the ones staring at a migration project.

Instrument to the standard, not to the vendor. That's the whole lesson.

The version you can build this week

If you're starting from nothing, don't build the full stack. Do this in order and stop when it hurts less:

1. Turn on N8N_OTEL_ENABLED and point it at a collector. One afternoon.
2. Add the clientId Set node to every client-facing agent workflow. One hour, and it's the highest-leverage step on this list.
3. Log tokens and cost per run with that identifier, even if it's just a Data Table to start.
4. Add Langfuse when reading raw spans stops being enough — usually around the point you're running more than a handful of agents.

Most agencies we talk to have step 1 half-done and steps 2 and 3 missing entirely. Step 2 is an hour of work and it's the one that changes how you price.

Want us to look at your agents?

If you're running AI agents in production and you can't answer "what did it decide and what did it cost" for a specific run, that's a fixable gap — and it's usually a smaller job than it feels like from the inside.

We build and maintain agent stacks like this as part of our n8n workflow automation work, across 200+ production workflows. Get a Free Automation Audit and we'll review your current setup, tell you where you're flying blind, and show you what it would take to fix it. No pitch deck, just the findings.

---

Sources: n8n's 2.x release notes for version and date details, and the OpenTelemetry tracing specification for the trace and span model referenced above.