Testing, debugging and the execution history

The main debugging tool in n8n is the execution history. Every run is recorded, and opening one shows each node's input and output — so you can trace what the data became at each step.

While building, three features make the work far easier:

• Partial execution — running one node and the part that depends on it
• Data pinning — freezing a node's output and using it on later runs instead of making the real request
• Data mocking — creating synthetic test data with Edit Fields or a Code node

Pinning is for development only — it does not apply to production executions. It is also possible only on nodes with a single main output.

A debugging sequence. When something breaks, this order saves time:

1. Open the failed execution in the history. See which node it stopped at — that narrows the search immediately. 2. Look at that node's INPUT data, not its output. Most failures are not in the node but in the unexpected shape of what reaches it: a missing field, an array, a null, a number where a string was expected. 3. Check the item count. More or fewer items than expected means the problem is further upstream. 4. Pin the data and re-run the node repeatedly. You iterate on the problem part without calling the real API again. 5. Simplify the conditions. In a complex condition, keep one clause at a time until you find the broken one.

To reproduce a production problem on the canvas, n8n can load data from a previous execution into the current workflow. It is the fastest cure for "works on my machine".