Debugging with Execution View: Inspecting Node Data

Hello! Welcome to your sixth lesson on n8n.

In our last session, we focused on the theoretical foundation of how n8n works with data. We established that all data moves between nodes in a specific structure: an array of JSON objects called items. You learned that understanding this structure is the key to building workflows, as nodes implicitly loop over these items.

Today, we transition from theory to practice. Knowing the data structure is step one; being able to see and verify it at every stage of your workflow is step two. This lesson is all about learning how to "look under the hood." You'll learn how to use n8n's Execution View, the primary tool for tracing data flow and, most importantly, for debugging.

As a developer, you're familiar with using debuggers to step through code and inspect variable states, or using console.log() to print values. The Execution View is n8n's equivalent—it's how you verify your assumptions and find out exactly why a workflow isn't behaving as expected. By the end of this lesson, you will be able to inspect node input and output data to effectively debug your workflows.

1. The Starting Point: The Execution Log

Every time your workflow runs, whether manually during testing or automatically in production, it creates a record. This record is stored in the Execution Log. This log is your entry point for investigating any past workflow run.

You can access it via the "Executions" panel in the n8n UI.

When looking at this log, you'll see two main statuses:

• Succeeded: The workflow ran from start to finish without any node throwing a critical error.
• Error: The workflow stopped prematurely because a node failed.

A crucial point to understand is that "Succeeded" does not always mean "correct." A workflow can run without errors but still produce the wrong outcome—for example, if it fails to find a user in a database but is configured not to treat this as an error. We'll see exactly how to debug both types of issues.

2. Dissecting the Run: The Execution Detail View

Clicking on any execution in the log opens the Execution Detail View. This is where the real inspection happens. It presents a read-only snapshot of your workflow, showing the exact path the data took and the data itself at every step.

When you click on a node in this view, you'll see its details, most importantly its Input and Output data from that specific run.

In this view, you can switch between several tabs to inspect the data:

• Table: A user-friendly, spreadsheet-like view. Great for a quick glance at the data.
• JSON: Shows the raw JSON data. Given your background, you will likely find this the most useful and precise view. It shows the full item structure we discussed in the last lesson.
• Schema: Displays the structure of the data (field names and types) without the actual values. This is helpful for understanding the data model at a glance.

The core principle of debugging is to move from node to node, checking if the Output of one node matches the expected Input for the next.

For a comprehensive reference on debugging executions, you can consult the official n8n documentation.

3. Active Investigation: Practical Debugging Techniques

Inspecting past runs is for analysis. Active debugging is for fixing. n8n has a powerful feature that lets you take the data from a past execution and load it into your live editor to test your fixes.

To get an overview of the key debugging features, let's watch a short video from the n8n team.

Now, let's apply these concepts to two common scenarios.

Scenario 1: The Hard Fail (A Node Turns Red)

This is the most straightforward case: a node encounters a critical error and stops the workflow. A common cause is trying to access data that doesn't exist.

The following video clip demonstrates a complete debugging process for this exact situation. A workflow is failing because a webhook trigger is receiving data that's missing an expected id field.

Scenario 2: The Silent Fail (Green, but Wrong)

This is a more subtle, but very common, problem. The workflow completes with all nodes showing a green "Succeeded" status, but it doesn't achieve the desired result. This often happens when a node is configured to not throw an error, even if it doesn't find the data it was looking for.

Inspecting the input and output data is the only way to catch this. The next part of the video demonstrates this perfectly.

Conclusion

You've now learned the most fundamental skill for building reliable n8n workflows: how to follow the data. Debugging in n8n is less about esoteric error codes and more about systematic inspection. By treating each node as a function with a distinct input and output, you can quickly pinpoint where data is being misinterpreted, is missing, or has the wrong structure.

Key Takeaways:

• The Execution Log is the starting point for investigating past workflow runs.
• The Execution Detail View allows you to inspect the input and output data (in Table, JSON, or Schema format) for every node in a completed run.
• The "Debug in Editor" feature is your most powerful tool, allowing you to pin data from a past execution to your live canvas to test fixes.
• Be aware of both "hard fails" (red nodes) and "silent fails" (green nodes but incorrect output). Both are diagnosed by inspecting the data flow.

In our next module, we'll dive deeper into Core Concepts, starting with the different kinds of Trigger nodes. Now that you know how to inspect the data a workflow produces, you'll be perfectly equipped to understand and handle the unique outputs of Schedule, Webhook, and Manual triggers.