Troubleshoot n8n errors by checking the execution history for failed runs, inspecting node input/output data, enabling debug logging with N8N_LOG_LEVEL=debug, and using the built-in error workflow feature. Most errors fall into credential issues, data format mismatches, API rate limits, or timeout failures, each with a specific diagnostic path.
Why Learn to Troubleshoot n8n Errors Systematically
When an n8n workflow fails, the error message alone rarely tells the full story. A systematic troubleshooting approach helps you find the root cause faster, whether it is a misconfigured credential, unexpected data format, API rate limit, or timeout. n8n provides several built-in tools for diagnosing issues: execution history with full data snapshots, per-node input/output inspection, configurable logging levels, and error trigger workflows. Learning to use these tools effectively saves hours of debugging and prevents recurring failures.
Prerequisites
- A running n8n instance (self-hosted or n8n Cloud)
- At least one workflow that has failed or is producing unexpected results
- For server-side logging: access to the terminal or Docker logs
- Basic understanding of n8n node types and data flow
Step-by-step guide
Check the execution history for failed runs
Check the execution history for failed runs
The execution history is your first stop for troubleshooting. Navigate to the Executions tab in the n8n editor (left sidebar). Filter by status to show only failed executions. Click on a failed execution to see the full workflow state at the time of failure. Each node shows whether it succeeded or failed, and you can click any node to see its input and output data. The execution that triggered the error is highlighted in red with the error message displayed directly on the node.
1// Execution history shows:2// - Timestamp of the execution3// - Status: Success, Error, or Running4// - Workflow name5// - Execution duration6// - Mode: Manual, Trigger, Webhook, or Retry7//8// Click a failed execution to see:9// - Which node failed (highlighted in red)10// - The exact error message11// - Input data that caused the failure12// - Output data from preceding nodesExpected result: You can see all failed executions with timestamps. Clicking one opens the workflow state showing exactly which node failed and why.
Inspect node input and output data
Inspect node input and output data
Most n8n errors are caused by unexpected data reaching a node. Click on the failed node, then examine the Input tab to see what data it received. Compare this to what the node expects. Common data issues include: missing fields the node requires, wrong data types (string instead of number), empty arrays when the node expects at least one item, and nested JSON structures that need flattening. Also check the previous node's Output to verify it is producing the expected data shape.
1// Common data issues to check:2//3// 1. Missing field:4// Expected: {{ $json.email }}5// Actual input: { "name": "John" } ← no email field6//7// 2. Wrong data type:8// Expected: number for price calculation9// Actual input: { "price": "29.99" } ← string, not number10//11// 3. Empty input:12// Expected: at least one item13// Actual input: [] ← no items, node has nothing to process14//15// 4. Nested data:16// Expected: {{ $json.name }}17// Actual input: { "data": { "user": { "name": "John" } } }18// Fix: {{ $json.data.user.name }}Expected result: You can see the exact data that reached the failed node and identify mismatches between expected and actual input.
Enable debug logging for server-side diagnostics
Enable debug logging for server-side diagnostics
When the execution history does not provide enough detail, enable debug logging on the server. Set N8N_LOG_LEVEL=debug to see HTTP requests, credential lookups, expression evaluations, and internal operations. This is especially useful for diagnosing authentication failures, network connectivity issues, and expression evaluation errors. Remember to switch back to info or warn after debugging to avoid log noise and potential security exposure.
1# Enable debug logging2export N8N_LOG_LEVEL=debug3export N8N_LOG_OUTPUT=console45# Restart n8n to apply6n8n start78# In Docker:9docker stop n8n10docker run -d --name n8n \11 -e N8N_LOG_LEVEL=debug \12 -p 5678:5678 \13 -v n8n_data:/home/node/.n8n \14 docker.n8n.io/n8nio/n8n1516# View logs in Docker:17docker logs n8n --tail 100 -f1819# After debugging, switch back:20export N8N_LOG_LEVEL=infoExpected result: n8n outputs detailed logs including HTTP request/response bodies, credential resolution, and expression evaluation details.
Diagnose common error categories
Diagnose common error categories
Most n8n errors fall into five categories, each with a specific diagnostic path. Identifying the category first saves time by focusing your investigation. Check the error message text and the node type to determine which category applies, then follow the corresponding troubleshooting steps.
1// Category 1: Credential errors2// Messages: "401 Unauthorized", "Invalid API key", "Authentication failed"3// Fix: Verify credentials in Settings → Credentials. Test by creating a new credential.45// Category 2: Data format errors6// Messages: "Cannot read property X of undefined", "Expected string, got object"7// Fix: Inspect the input data on the failing node. Add a Set or Code node to transform data.89// Category 3: Rate limit errors10// Messages: "429 Too Many Requests", "Rate limit exceeded"11// Fix: Add a Wait node between API calls, use SplitInBatches, or reduce trigger frequency.1213// Category 4: Timeout errors14// Messages: "ETIMEDOUT", "Timeout exceeded", "socket hang up"15// Fix: Increase node timeout in Settings, check API server status, reduce request payload.1617// Category 5: Expression errors18// Messages: "Expression evaluation error", "Cannot read property of null"19// Fix: Check expression syntax. Use optional chaining: {{ $json.field?.subfield }}.Expected result: You can categorize any n8n error into one of five types and follow the specific diagnostic steps for that category.
Set up an error trigger workflow for automated monitoring
Set up an error trigger workflow for automated monitoring
Instead of manually checking for failures, create a dedicated error monitoring workflow. Add an Error Trigger node as the start of a new workflow. It fires whenever any workflow in your n8n instance fails. Connect it to notification nodes (Slack, email, or database) to log error details automatically. This gives you proactive monitoring so you discover failures immediately instead of hours or days later.
1// Error monitoring workflow2// Node 1: Error Trigger3// Node 2: Code node to format the error4const execution = $json.execution;5const workflow = $json.workflow;67return [{8 json: {9 alert: `Workflow "${workflow.name}" failed`,10 error: execution.error?.message || 'Unknown error',11 executionId: execution.id,12 timestamp: new Date().toISOString(),13 mode: execution.mode,14 url: `https://n8n.example.com/execution/${execution.id}`15 }16}];1718// Node 3: Send to Slack, Email, or save to databaseExpected result: Every workflow failure triggers an automatic notification with the workflow name, error message, and a link to the failed execution.
Complete working example
1// Code node: Automated troubleshooting data collector2// Add this to any workflow for debugging — it captures the full context34const items = $input.all();56// Collect environment info7const debugInfo = {8 // Workflow context9 workflowName: $workflow.name,10 workflowId: $workflow.id,11 executionId: $execution.id,12 executionMode: $execution.mode,13 timestamp: new Date().toISOString(),1415 // Input data summary16 inputItemCount: items.length,17 inputFields: items.length > 0 ? Object.keys(items[0].json) : [],18 firstItem: items.length > 0 ? items[0].json : null,1920 // Data validation checks21 checks: {22 hasItems: items.length > 0,23 firstItemHasData: items.length > 0 && Object.keys(items[0].json).length > 0,24 noErrorField: items.length > 0 && !items[0].json.error,25 allFieldsPresent: items.length > 0 && !Object.values(items[0].json).includes(undefined)26 }27};2829// Flag any issues30const issues = [];31if (!debugInfo.checks.hasItems) issues.push('No input items received');32if (!debugInfo.checks.firstItemHasData) issues.push('First item is empty');33if (!debugInfo.checks.noErrorField) issues.push('Error field detected in input');34if (!debugInfo.checks.allFieldsPresent) issues.push('Some fields are undefined');3536debugInfo.issues = issues;37debugInfo.status = issues.length === 0 ? 'OK' : 'ISSUES_FOUND';3839// Pass through original items plus debug info40return [41 {42 json: {43 _debug: debugInfo,44 ...items[0]?.json45 }46 },47 ...items.slice(1)48];Common mistakes when troubleshooting n8n Errors
Why it's a problem: Looking only at the error message without checking the input data
How to avoid: Most errors are caused by unexpected input data. Always inspect the Input tab on the failing node to see what data it received.
Why it's a problem: Leaving N8N_LOG_LEVEL=debug in production permanently
How to avoid: Debug logs can expose sensitive data and consume disk space. Set it to debug only for active troubleshooting, then revert to info or warn.
Why it's a problem: Not saving execution data for failed runs
How to avoid: Set EXECUTIONS_DATA_SAVE_ON_ERROR=all in your environment variables so failed executions are always saved for later inspection.
Why it's a problem: Ignoring intermittent errors because they resolve themselves
How to avoid: Intermittent errors often indicate rate limits, timeouts, or resource constraints that worsen over time. Investigate and add error handling.
Best practices
- Always check the execution history first — it shows exactly which node failed and what data it received
- Inspect both input and output on the failing node to understand the data flow
- Enable debug logging temporarily for hard-to-diagnose issues, then switch back to info level
- Set up an error trigger workflow to receive immediate notifications about failures
- Save execution data for both successful and failed runs to compare behavior
- Use data pinning to reproduce errors with the exact same input data
- Document common errors and their solutions in your team's knowledge base
- Test each node individually using the Execute Node button before running the full workflow
Still stuck?
Copy one of these prompts to get a personalized, step-by-step explanation.
My n8n workflow is failing with 'Cannot read property of undefined'. How do I systematically debug this by inspecting node input/output data and identifying which field is missing?
Help me set up a systematic error monitoring workflow in n8n with an Error Trigger that sends Slack notifications with the workflow name, error message, and execution link.
Frequently asked questions
Where do I find the error message for a failed workflow?
Go to the Executions tab, click on the failed execution, and click the red-highlighted node. The error message appears in the node's output panel with details about what went wrong.
How do I re-run a failed execution with the same data?
In the execution history, click on the failed execution, then click the Retry button. This re-runs the workflow with the same input data from the original execution.
Can I get notified automatically when a workflow fails?
Yes. Create a separate workflow with an Error Trigger node as the start. Connect it to a notification node (Slack, email, etc.). The Error Trigger fires whenever any workflow in your n8n instance encounters an error.
Why does my workflow work manually but fail when triggered?
Manual and triggered executions may receive different data. Manual runs use pinned data or simplified test data, while triggers receive real-world data that may have missing fields, different formats, or edge cases.
How long are execution logs kept?
Configure retention with EXECUTIONS_DATA_PRUNE=true and EXECUTIONS_DATA_MAX_AGE (in hours). Default behavior varies by version. Set these explicitly to ensure failed executions are available for investigation.
What should I do if I cannot find the error in n8n?
Enable N8N_LOG_LEVEL=debug, reproduce the error, then check the server logs for HTTP request details and internal errors that do not appear in the UI.
Can RapidDev help me diagnose and fix persistent n8n errors?
Yes. RapidDev can audit your n8n workflows, identify error patterns, and implement robust error handling and monitoring. Contact RapidDev for a free consultation.
Talk to an Expert
Our team has built 600+ apps. Get personalized help with your project.
Book a free consultation