How to Debug Workflows in n8n

Click the Executions tab at the top of the n8n editor (next to the Editor tab). This shows a list of all past executions for the current workflow, sorted by most recent first. Each row shows the execution status (Success, Error, or Running), the start time, the execution duration, and the trigger type. Click on any execution to load it in the editor with all node outputs preserved. Failed executions are highlighted in red and show the error message inline. Use the filter options to show only failed executions when investigating errors.

After loading a past execution, click on any node in the workflow canvas to see its output data. The output panel shows what data the node produced after running. Switch between Table view and JSON view to explore the data structure. Table view is easier to scan for large datasets, while JSON view shows the exact data structure including nested objects. Compare the output of one node with the input of the next node to find where data gets lost or transformed incorrectly. Click the Input tab to see what data the node received.

When a workflow execution fails, the failing node is highlighted with a red border on the canvas. Click on it to see the error message in the output panel. n8n error messages typically include the HTTP status code (for API calls), the error type, and a description from the external service. Common patterns include 401 (authentication failure), 400 (invalid request data), 429 (rate limit), and 500 (server error). The error message often tells you exactly what to fix — read it carefully before making changes.

Data pinning lets you freeze a node's output so downstream nodes can be tested without re-running the entire workflow. This is especially useful when the trigger is a webhook (which requires re-sending a request) or an external event. After inspecting a node's output, click the Pin icon in the output panel. The pinned data persists and is used every time you test downstream nodes. You can also manually edit pinned data to test edge cases. Unpin the data when you are done debugging to restore normal flow.

For issues that are not visible in the node output, enable detailed logging by setting the N8N_LOG_LEVEL environment variable. The default level is info. Set it to debug for verbose output that includes internal data processing details, or to warn to only see warnings and errors. Check logs using your deployment's log viewer. For Docker, use docker compose logs n8n. Detailed logs show HTTP request and response details, credential resolution, expression evaluation, and internal node processing steps.

1# Enable debug logging
2# In docker-compose.yml:
3environment:
4  - N8N_LOG_LEVEL=debug
5
6# In .env file:
7N8N_LOG_LEVEL=debug
8
9# View logs in Docker:
10docker compose logs -f n8n
11
12# View logs with timestamp filtering:
13docker compose logs --since 5m n8n
14
15# Log levels: error, warn, info (default), debug

For complex workflows, insert a Code node to log specific data points to the n8n console. Use console.log() in the Code node to output values to the n8n server logs. This is useful for inspecting intermediate values that are not easily visible in the node output, such as computed expressions, loop counters, or conditional logic results. Label your log messages clearly so you can find them in the logs.

1// Code node: Debug logger
2const items = $input.all();
3
4for (const item of items) {
5  console.log('[DEBUG] Item data:', JSON.stringify(item.json, null, 2));
6  console.log('[DEBUG] Item keys:', Object.keys(item.json));
7  console.log('[DEBUG] Has expected field:', 'email' in item.json);
8}
9
10// Pass items through unchanged
11return items;