Debug the failed run, not the whole workflow.

When an n8n workflow fails, the fastest useful question is usually not “how should I rebuild this automation?” It is “which node failed, what evidence did n8n record, and what category of failure is this?”

1. Preserve the failure evidence

Keep the exported workflow and the saved failed execution as separate artifacts. Remove unnecessary sensitive data before sharing either one. The workflow explains the graph; the failed execution explains what actually happened during that run.

2. Identify the failing or last executed node

Start with structured execution data rather than the most dramatic-looking log line. Record the node name, node type, status code when available, and the sanitized error message.

3. Normalize the root cause

A small set of categories covers many operational incidents:

• authentication — 401/403, expired credentials or missing scope;
• rate limit — 429 or an upstream quota response;
• timeout/network — reachability, DNS, socket or time-budget failures;
• invalid input — validation, malformed request or 400/422 responses;
• expression/item-linking — undefined fields or data-shape mistakes;
• execution error — structured failures that do not fit a more specific class.

4. Treat retry safety as a separate decision

A retry can be reasonable for a bounded transient failure such as a rate limit or some timeouts. It can be dangerous when the failed node performs a non-idempotent side effect. Classification and retry policy should not be collapsed into one guess.

5. Retest only the failing path first

After fixing the suspected cause, test the smallest path that proves the fix. Rewriting unrelated nodes makes it harder to know what actually solved the incident.

When batch incident reports help

Incident Doctor Pro processes multiple failed-execution items in one run and adds severity, retry-safety guidance, workflow risk hints, sanitized evidence, and a ready-to-copy Markdown incident report.

Prevent duplicate executions with idempotency →