Reading executions and fixing failed runs
🎯You'll be able to
Use an execution's saved data to find the failing node, the input that caused it and a safe way to re-run.
🏠The everyday picture
When a parcel goes missing, the courier's tracking history shows each scan: picked up, reached the hub, out for delivery. You find where it stopped. An execution log does the same for a workflow.
📘What it really is
-
Every run is saved as an execution, with its status (success, error, running or waiting) and the data each node received and produced.
-
To investigate a failure:
- open the failed execution;
- find the node with the error, read its message (for example "401 Unauthorized" or "Cannot read properties of undefined");
- check the input that node received: was a field missing, empty or in the wrong format?
-
fix the workflow, then retry the execution.
-
An error workflow starts with the Error Trigger node and runs whenever a chosen workflow fails. Use it to send an alert with the workflow name, the failed node and a link to the execution.
-
Keep executions long enough to investigate, but not forever; old executions take space and may hold personal data. n8n lets you set how long they're kept.
📝A worked example
Monday morning, the Sharma Textiles daily list didn't arrive. You open Executions and find the run failed at the Google Sheets node with "The caller does not have permission". The input looks fine, so the problem is access. The sheet's owner had removed the service account while tidying sharing settings. You re-share the sheet, retry the execution, and the list is sent. You also connect an error workflow so next time the alert arrives at 8:01 am, not when someone notices.
🌍Where it's used
- Support work: the first thing an automation specialist does when a client says "it stopped working".
- Monitoring: error workflows send alerts to email, Slack or WhatsApp.
- Audits: execution history shows what was sent, when and with what data.
- Improving workflows: frequent failures at one node point to a weak spot to redesign.
📝Case scenario
A client says customers got two shipping messages each yesterday. In the executions list you see each order triggered the workflow twice, a few seconds apart: the shop platform had retried its webhook because your workflow replied slowly. You add a check that skips orders already processed (you'll build this properly in DA6) and make the webhook reply straight away.
🖱️Try it
Break your workflow on purpose: remove the sheet permission or rename a column. Run it, open the failed execution, find the cause from the error and input data, fix it and retry. Then build an error workflow that emails you the workflow name and failed node.
⚠️Common mistakes
- Re-running a failed execution without checking what already happened. Sign: duplicate messages after a retry. Fix: check which steps succeeded and make writes idempotent (DA6) before retrying.
- Reading only the error message. Sign: the fix doesn't hold. Fix: look at the input the node received; the cause is usually there.
🛠️For your project
When an acceptance test fails, open the execution for that run and find the node and input that caused it. Note what you found in your test evidence.
✅Quick check
What two things should you look at first in a failed execution?
Show the answer
The error message on the failed node, and the input data that node received.
What does an error workflow do?
Show the answer
It starts automatically when another workflow fails and sends an alert with details, so failures are noticed quickly.