n8n Event Logs: An Exercise to Trace a Workflow Failure
A hands-on exercise in reading n8n event logs and execution data to find exactly which node failed, read its error, and confirm the likely cause.
Checked against the cited sources on .
Editorial exercise: what you'll trace and why
This is an editorial exercise, not a report on a test we ran: it walks through how to read n8n event logs and execution data to trace a workflow failure down to one node and one cause. You will build a small workflow that fails on purpose, then follow n8n's own tools to find out exactly where and why it broke. The goal is a repeatable habit you can apply the next time a real workflow fails in production.
You need an n8n environment, cloud or self-hosted, where you can create and run workflows, plus a workflow containing at least one node that can fail. If you self-host, keep in mind that n8n's documentation ties re-running and debugging a past execution to your edition: on a self-hosted instance this is available on Registered Community, Business and Enterprise setups, but not on an unregistered free install.
For the input, use n8n's own Stop And Error node, which n8n's documentation describes as a way to force an execution to fail under conditions you choose, or point an HTTP Request node at an invalid URL. Either gives you a reproducible failure to chase through the rest of this exercise.
Two features in this exercise are plan-gated, not universally available. Debug in editor depends on your self-hosted edition and registration status, and n8n's documentation restricts Log Streaming, the mechanism behind cross-system event logs, to Enterprise plans on both n8n Cloud and self-hosted. We think that gating is a reasonable way for n8n to reserve its heaviest operational tooling for teams running it at scale, but it does mean a solo learner on a free community install should expect to stop short of the optional last step.
| Feature | Self-hosted availability | n8n Cloud availability |
|---|---|---|
| Debug in editor | Registered Community, Business, Enterprise | All plans |
| Log Streaming (event logs) | Enterprise | Enterprise |
Sources: Handle errors gracefully | Build | n8n Docs, Debug executions | Build | n8n Docs, Stream logs to external systems | Administer | n8n Docs
Steps 1–2: Find the failed run and read the error
Step 1 is to open the Executions list. n8n's own error-handling documentation recommends reviewing Executions, for a single workflow or across every workflow you can access, as the first move when investigating a failure. Find the run marked as failed; it is the execution your Stop And Error node or broken HTTP Request just produced.
Step 2 is to open that failed node's output. A community blog on debugging n8n workflows describes clicking the failed node inside the Executions tab to see detailed JSON describing what input it received and why it failed; treat that as one practitioner's description of the interface rather than official documentation. From the same failed execution, n8n's own docs describe a Debug in editor option that loads that execution's data back into your current workflow so you can fix the problem and rerun it. The plan restriction from the previous section still applies: on self-hosted n8n this only works on a registered Community, Business or Enterprise install.
- Open the Executions list for your workflow
- Click into the execution marked as failed
- Open the node that failed to read its error output
- Select Debug in editor to pull that run's data into the canvas
Sources: Handle errors gracefully | Build | n8n Docs, Debug executions | Build | n8n Docs, n8n Debugging & Error Handling Basics [2026 Blueprint]
Steps 3–4: Correlate with an error workflow and debug logs
Step 3 moves from inspecting one run by hand to catching failures centrally. n8n's documentation requires that a dedicated error workflow start with the Error Trigger node before you can set it as a workflow's error workflow. Build one, point your test workflow's error workflow setting at it, and trigger your failure again. That Error Trigger execution's own data already includes a lastNodeExecuted field naming the node that was running when the execution failed, on any plan or edition. Where Log Streaming is configured, the separate n8n.workflow.failed event carries its own lastNodeExecuted field too, giving you a second, independent confirmation of the same node name.
Step 4 adds detail at the application-log level. n8n's logging documentation describes debug as its most verbose log level, meant to help developers debug issues, and its environment-variable reference lets you choose where those logs go, console or file.
Turn debug logging on only while you are actively chasing this failure, then turn it back down; n8n's own guidance encourages including identifiers like executionId and workflowId in log lines so a failure can be traced across them, though that is advice for n8n's own log output rather than a guarantee every line you see already does it. We'd treat debug-level logging as a temporary magnifying glass, not a setting to leave on in production.
Sources: Handle errors gracefully | Build | n8n Docs, Stream logs to external systems | Administer | n8n Docs, Set up logging | Deploy | n8n Docs, Logs | Deploy | n8n Docs
Step 5 (optional): Trace further with n8n event logs
Step 5 is optional and only works if your plan supports it: Log Streaming is n8n's name for sending workflow and audit events, including n8n event logs about a failed run, to an external system such as a SIEM or log aggregator. n8n's documentation restricts this to Enterprise plans, on n8n Cloud and self-hosted alike, so most learners on lower plans will skip straight to the completion step.
Where it is configured, the n8n.workflow.failed event carries that same lastNodeExecuted field, which lets a team search for the failing node across many workflows from one external system instead of opening each workflow's Executions list in turn. For a learner without Enterprise access, reading about this step still helps: it shows what centralized n8n event logs add beyond what a single workflow's Executions list can show.
Sources: Stream logs to external systems | Administer | n8n Docs
Completion criteria and reflection
You've completed this exercise when you can name three things from your own test run: the exact node that failed, the error message it produced, and a one-sentence explanation of the likely cause, such as an invalid URL or a deliberately triggered Stop And Error. If you built an Error Trigger workflow, you should also be able to point to the same node name in its execution data. That three-part answer is the core reading skill n8n event logs are meant to support.
A common pitfall in this exercise, and in real incident response, is reaching for automatic retries before reading the error at all. Automation architect Alfaz Mahmud Rizve makes the relevant distinction on his own blog about n8n debugging and error handling: some failures will repeat no matter how many times you retry, and those call for proper error handling rather than another attempt.
In our reading of n8n's own documentation, the habit that helps most is building the Error Trigger workflow before you need it, not after the first production failure. We think that one habit, cheap to set up on any plan, does more for a team's reliability than any single plan upgrade.
Sources: Handle errors gracefully | Build | n8n Docs
