Why is my n8n workflow not working, and how do I find out?

Where do I look first: Executions, and what do they not show?

The Executions tab is the first stop for any failure. It shows the status of every run, the node it stopped on, and the full stack of input data at each step up to the point of failure. That's enough for most cases: click the red execution, open the node, look at what it received, and you'll usually see straight away that a field was empty or had the wrong type.

Executions doesn't show three things that trip people up regularly, though.

First, it doesn't show what never ran at all. If a webhook never arrived or a schedule missed due to the wrong server timezone, Executions carries no trace of it. Check the trigger itself separately: a webhook test through Postman or curl, a schedule through a Code node calling new Date() to see the server's actual clock.

Second, if execution saving is turned off in the workflow's Settings, the tab is simply empty even though the workflow is running in the background. The setting makes sense on high-volume workflows, where every execution would add a database row and fill the disk within weeks, but turning it off on the first production run takes away your own ability to debug. Turn it off only after the workflow has passed testing.

Third, a red execution doesn't always mean a technical error. An IF node taking the false branch because the data didn't meet the condition is usually correct behaviour, not a failure. Check whether the outcome was actually supposed to be different before hunting for a cause.

Why does the agent (or the client) not connect to n8n at all?

This is a separate category, because it happens before the workflow ever starts running. Telemetry from AI agents building workflows in n8n shows 43% of connection tests to the n8n API fail: 76% of those are a wrong address or an unreachable network, followed by a wrong API path, and finally no response at all. A handful of questions, asked in order, usually finds it.

Is the address correct? The most common mistake is a URL missing /api/v1, http instead of https, or the editor's address used instead of the instance's API address. Behind a reverse proxy, internal and external addresses can differ, and the agent sometimes gets handed the internal one.

Can the network reach the instance at all? On an internal network or behind a VPN, an agent connecting from outside gets a timeout or a refusal, which the telemetry classifies as an address error since it looks identical to a wrong URL from the client's side.

Is the API path current? Rarer but real: after an update, n8n changes some endpoints' structure, and an old client calling the old path gets NOT_FOUND instead of data.

A specific case from a client: an agent got a 403 fetching the credential list, though the same key had worked fine before. It had been created before an update that introduced a new, more granular API permission level, so it didn't cover the new resource. Fix: Settings, n8n API, Rotate, a new key with full permissions. Since then I set keys to expire after 90 days, so the same problem surfaces on its own rather than a two-year-old key quietly going stale.

Why does the workflow fail in a node that used to work?

If the node's configuration hasn't changed but it stopped working, the cause usually sits outside the workflow.

The language model got retired. I've seen this twice: Google retired the Gemini 2.5 series and a workflow using it started returning errors instead of answers; a client's two-year-old project stopped working because Anthropic retired Haiku 3. The fix is a simple model swap, but you have to find out about the retirement before the workflow starts throwing errors. A quarterly review of the model versions in use is now standard maintenance for any automation with an LLM node.

A brand-new model isn't supported by the node yet. The opposite case: a provider ships a fresh model, someone picks it from the list, and n8n's node for that provider returns something like "Malformed function call," because the response format differs from what the node expects. It's usually days or weeks before n8n catches up; until then, stay on the previous version.

Cookies expired. Common in workflows scraping an app with no public API through an HTTP Request node with session cookies baked into the credentials. The session expires and the node starts getting a login page instead of data. What works for me: wire the error output to a notification, keep the cookies in a Data Table instead of hardcoded, and run a separate refresh workflow that logs in periodically and updates the table.

The upstream data changed shape. A spreadsheet gained a column, an API renamed a field, a form got a new question. A node relying on fixed indexes or names breaks. That's not an n8n bug, just an automation assuming a fixed shape while something on the other side changed it without warning.

Why does the AI Agent node hallucinate or return garbage?

The most common cause in workflows built without n8n experience: instructions describing how the agent should work end up in the user message, leaving the system message empty or the default "you are a helpful assistant." The model then has no stable operating context, just instructions bundled with data in one message, which lowers quality even though the same prompt works fine in a plain chat. The rule: the system message says how the agent works, the user message carries only the data.

A second cause is a Data Table "If row exists" returning an empty object instead of the expected result. The agent sees what looks like missing data even though the row exists, and starts guessing or claiming there's nothing there.

A third is the hard 4 kB limit on tool responses in n8n Agents. A connected tool that returns a raw scraped HTML page or a full data row instead of a summary gets its response cut off. To the agent it looks like the tool isn't working, even though the sub-workflow ran fine. Fix: return processed text, not raw data.

Why does nothing happen at all, i.e. silent failures?

This is the worst variant, because nobody knows there's a problem until someone stumbles on it. At one client, a workflow stopped working after a change on an external API's side, and nobody noticed for two weeks, because nobody had a reason to open Executions every day. The client only found out when missing data showed up somewhere else.

This is exactly what an error workflow protects against: without one, information about a failure lives only in Executions, for whoever thinks to look. With one, the information comes to a person on its own, within seconds, through a channel they already check daily: team chat, the task manager, email.

Another variant of a silent failure is a trigger that never fires. A schedule set in the wrong timezone fires at three in the morning instead of nine, before the day's data is ready, and the workflow finishes without an error but with an empty result. It's worth checking the actual run time occasionally, not just the schedule's configuration.

Which n8n behaviours trip everyone up (the pitfalls list)?

A handful of n8n mechanics work differently from what intuition suggests, and cause the same failures over and over.

Execute Workflow with a Wait node in the sub-workflow. Data can fail to return properly to the parent once the wait ends. Build a webhook-based pattern instead of a Wait inside the sub-workflow.

SplitInBatches with a Wait in the same loop. The batch iterator's state doesn't survive the wait, so items get skipped or reprocessed. Process batches synchronously, or use a queue.

Append on a Google Sheet with formula columns. Append writes raw values, including a formula's computed result as plain text, and permanently overwrites the formula. Update with a specific cell range is safer wherever the sheet computes something itself.

$env unavailable inside a Code node. A deliberate security restriction, not a bug. Pass environment variables another way, for example through the workflow's input or static data.

saveExecutionProgress fills the disk. It saves state after every node, useful for critical workflows that need to resume, but at high volume it can fill a disk within days. Check available space first.

IF branches are "true" and "false," not numbers. Wire nodes after an IF to the named branch, not an output number. Switch works the same way, with names matching the rules.

$input.all() versus $input.first(). Grabbing only the first item when several arrive is a classic Code node mistake. With multiple items, use $input.all() with iteration, or run-once-per-item mode.

Per-item execution on large datasets. Google Sheets queries the API once per row by default. At a hundred rows or more that's slow and easy to rate-limit. Batch operations, or Append or Update with multiple rows at once, run much faster.

A webhook's response must be sent explicitly. With Using Respond to Webhook Node mode, the workflow needs a Respond to Webhook node, or the caller waits until timeout. For a simple acknowledgment, When Last Node Finishes is enough.

The Error Trigger must live in a separate workflow. It can't catch errors in its own workflow. It has to sit in a dedicated error-handling workflow, wired in through Settings, Error Workflow, on every workflow you want monitored.

$getWorkflowStaticData('global') in loops. In a Code → HTTP Request → Code → If → HTTP Request loop, the HTTP Request node overwrites $json with the API's response, so any counter or accumulated data held in $json is lost. Keep loop state in the workflow's static data instead, and reset it at the start of every run, since it persists in the database between runs and stale data from a failed execution can leak into the next.

How do I set up error handling on three levels?

This is the setup I use on every production workflow, and it catches almost everything before it grows into a silent failure.

Level one: Retry on Fail on every node that talks to an external service. Google Drive, Google Sheets, any API. Three attempts with a wait between them catch the large majority of transient failures: a brief timeout, a momentary overload, a short network blip. It's the cheapest layer of protection and should be the default, not the exception.

Level two: On Error set to Continue using error output for errors you expect. Instead of stopping the whole workflow, the node gets a red error output you can wire further. I route mine to a team chat notification carrying the node's name and the error text, so it's clear exactly what broke and where, without opening Executions.

Level three: a separate error workflow for errors you didn't expect. Set it in the workflow's Settings, in the Error Workflow field, on every production workflow individually. It starts with an Error Trigger node and does two jobs: filter out noise, and get the signal to a person. A filter at the start drops transient errors, like a brief timeout or a momentary Google Drive outage, so the team isn't flooded with alerts about something that fixes itself on retry. What passes the filter goes to two places in parallel: a task in the task manager assigned to the workflow's owner, and an alert to a Google Chat room through an incoming webhook.

Any active workflow running on a schedule or webhook, doing something real with nobody watching live, needs that third level. An interactive workflow, run manually and watched during testing, can do without it, since you see the failure on screen right away.

How do I debug with an AI agent without making a mess?

A few habits that work well when debugging with an agent's help, for example through n8n-mcp, without the agent actually breaking something during testing.

Disable action nodes with the D key before running a test. Data flows through the whole workflow, but nothing reaches an external system: no email goes out, no record gets written. Test as many times as you like with no side effects, and the agent still sees the full data flow, including where it breaks.

Log results to a Data Table instead of paging through executions by hand. Run the workflow in shadow mode for a few days, have every run append a row with its input, output and status, then have the agent review the table and point out where the prompt or logic needs fixing. That beats clicking through Executions one at a time.

Build a set in the Evaluations tab for workflows with a model node: a regression test for the prompt, a set of queries run after every change and scored for quality, so you see immediately whether a fix helped or broke something else. Through n8n-mcp an agent can build such a set on its own from a description of what the workflow should do.

After every n8n update, do a hard refresh, Ctrl or Cmd plus Shift plus R. The interface sometimes shows stale state from before the update until the browser cache clears, which looks like a workflow bug even though it's just an old UI render.

Finally, if an agent debugs on a production instance, make sure execution saving is on before it starts. Without it, the agent gets exactly as much information as a person staring at an empty tab: none.