How to debug workflows in n8n?

A reliable way to debug workflows in n8n is to run the workflow in the Editor UI, activate Manual Execution, inspect every node’s Input and Output data, and use Execution Logs to review what happened. The key is to look at the data flowing between nodes and isolate where it changes in an unexpected way. You can also use Error Workflow, Debug nodes like Set/Function, and the Execution Preview to trace values. n8n debugging is really about watching the JSON move step‑by‑step.

 

The Core Things to Do When Debugging in n8n

 

To debug in n8n, you want to slow things down and look at the actual data that each node receives and sends forward. n8n executions are just a chain of nodes passing JSON. Problems usually come from wrong assumptions about that data, missing fields, incorrect expressions, or API responses not matching what you expected. The tools below are how you uncover that.

• Use Manual Execution: It lets you run the workflow step‑by‑step inside the Editor so you can inspect each node.
• Check Node Input/Output: Every node shows exactly what data it received and what it produced. This is the single most important debugging technique.
• Use the Execution Logs: These show past runs, including errors, raw responses, and stack traces for Function nodes.
• Inspect Fehler Screens: When a node errors, n8n shows the message, the payload, and often the failed HTTP response.
• Use Expressions Panel: Hovering over an expression shows the resolved value, which helps catch undefined or wrong paths.
• Log inside Function nodes: Using console.log sends output to the execution data so you can see it later.
• Add a temporary Set node to snapshot data at specific points.
• Configure an Error Workflow to capture errors and notify you with full execution details.

 

How to Debug Step-by-Step

 

Here’s the practical approach I use in production when debugging a workflow.

• Start with Manual Execution. This mode shows live node‑by‑node output. Great for testing triggers that accept manual data (like Webhook with Test URL).
• Trigger the workflow with real sample data. If it's a Webhook trigger, send a real request using a tool like Postman or curl to the Test URL. This gives you the exact JSON shape you're working with.
• Check each node’s Incoming Data panel. This is often where the “aha” moment happens—maybe the field you thought was data.id is actually payload.user.id.
• Hover over all expressions. In n8n, an expression like {{$json["email"]}} might resolve to undefined and you won’t know unless you hover. That’s how you see what the workflow actually sees.
• Temporarily insert Set nodes. Example: if you're not sure what an API returned, drop a Set node after the HTTP Request node and map {{$json}} into a property called debug. This helps expose nested objects.
• Use Function nodes to log. For example:

// Use console.log() to inspect deep structures
console.log($json);  

return items; 

• This log appears in the Execution page under the Function node, which helps understand what's going on.
• Check Execution Logs. For long‑running or production workflows, look at “Executions” in the left sidebar. Each run shows the full history, inputs, outputs, retries, and timestamps.
• If a workflow fails silently, make sure Save Data > On Error is enabled in Settings so you can inspect partial runs.

 

Debugging HTTP/API Calls

 

API calls are the most common source of errors, so here’s how to debug them properly.

• Look at the Raw Response tab in the HTTP Request node. This shows the real body the API returned.
• Check the Status Code. A 400/401/403/500 always gives clues.
• Disable "Simplify Response" temporarily to see the full structure with headers and body.
• Validate request data by checking the node's "Request" tab—headers, payload, URL, etc.

 

Debugging Expressions

 

Most expression problems in n8n come from referencing the wrong path. Use the Expression Editor to preview values, and rely on the Autocomplete list on the right side. When in doubt, print the whole object with a Function node and inspect it.

 

Using Error Workflows

 

If you're debugging something that only breaks in production, you can attach an Error Trigger workflow. When the main workflow fails, n8n starts the error workflow and passes:

• $json containing error details
• Execution ID
• Stack trace (if applicable)
• Failed node name

This is extremely useful when workflows run at night, when rate limits hit, or when webhook payloads change.

 

When Debugging Becomes Architecture Work

 

Sometimes the root cause is not a node bug but workflow design: too many items, long loops, or API rate limits. If a workflow keeps breaking in later nodes, consider splitting it into sub‑workflows, adding rate limits, or using queues.

 

The main idea: debugging in n8n means inspecting data at every step, confirming assumptions, and using the tools n8n gives you: Manual Execution, Node I/O, Expression previews, logs, and error workflows. Once you get used to watching the JSON flow through, debugging becomes fast and predictable.