n8n Logging: The Complete Guide to Debug, Monitor, and Troubleshoot

Your n8n workflows are failing, and you have no idea why.

The execution shows “Error” in red. The error message says something cryptic about “Cannot read properties of undefined.” You check the node, stare at the data, and wonder what went wrong. Your console.log() statements produce nothing. The server logs show nothing relevant. You’re flying blind.

This scenario repeats constantly in the n8n community. Users build complex automations, deploy them to production, and then discover they have zero visibility into what’s actually happening inside their workflows.

The Silent Failure Problem

n8n’s default configuration prioritizes simplicity over observability. Out of the box, you get basic execution logs in the UI and minimal server output. For development, that’s fine. For production workloads handling customer data, processing orders, or managing business-critical operations, it’s a liability.

When workflows fail silently, problems compound. A broken API call might cascade into data inconsistencies. A rate-limited webhook might drop requests without anyone noticing. Without proper logging, you’re always reactive rather than proactive.

Why n8n Logging Is Different

Traditional application logging is straightforward: your code writes messages, they appear in a file or console. n8n’s architecture complicates this.

Workflows are node-based, meaning execution jumps between discrete components rather than flowing through sequential code. Each node processes data independently. When something breaks, you need to know which node failed, what data it received, and what error occurred.

n8n also has multiple execution contexts. Manual executions (when you click “Test workflow” in the editor) behave differently from production executions (triggered by webhooks or schedules). This distinction catches many users off guard, especially when debugging Code nodes.

If you’re running queue mode with distributed workers, logging becomes even more complex. Logs scatter across multiple containers. Correlating a single execution across the main instance and worker processes requires intentional setup.

What You’ll Learn

• How n8n’s log levels work and when to use each one
• Every environment variable for controlling log output
• Where to find logs in Docker, npm, and cloud deployments
• Why console.log() doesn’t work in Code nodes (and how to fix it)
• Setting up production monitoring with health endpoints and metrics
• Building alerting workflows with Error Trigger
• Troubleshooting the most common logging problems

How n8n Logging Works

n8n uses the winston logging library under the hood. Winston is battle-tested Node.js logging that supports multiple output destinations, log levels, and formatting options.

Understanding log levels is the foundation of effective n8n logging. n8n supports four levels, ordered from least to most verbose.

Log Levels Explained

Level	What It Captures	When to Use	Performance Impact
error	Critical failures only	Minimal production logging	Lowest
warn	Potential issues and errors	Recommended for production	Low
info	General status and execution flow	Default setting, good for development	Moderate
debug	Everything including internal operations	Troubleshooting only	High

The default level is info, which captures general operational messages but omits detailed debugging information. For most production deployments, warn provides better signal-to-noise ratio while still capturing important issues.

Warning: Debug mode generates massive amounts of log data. Enable it only temporarily when actively troubleshooting. A busy n8n instance can produce gigabytes of debug logs in hours, filling disk space and impacting performance.

What Each Level Captures

Error level logs only failures that require attention: workflow execution failures, database connection problems, critical system errors. If you set N8N_LOG_LEVEL=error, you’ll see only these critical issues.

Warn level adds potential problems: deprecated features, rate limiting warnings, retried operations, configuration issues. This level balances visibility with log volume and works well for production.

Info level adds operational context: workflow starts and completions, webhook registrations, schedule activations, general status messages. Useful for development and debugging but potentially noisy in high-volume production.

Debug level adds everything else: internal function calls, data transformations, authentication flows, queue operations. Essential for deep troubleshooting but overwhelming for regular use.

Essential Logging Environment Variables

n8n’s logging behavior is controlled through environment variables. Here’s every variable you need to know.

Core Logging Variables

# Set the logging level (error, warn, info, debug)
N8N_LOG_LEVEL=warn

# Set where logs go (console, file, or both)
N8N_LOG_OUTPUT=console,file

# Custom log file location (default: <n8nFolder>/logs/n8n.log)
N8N_LOG_FILE_LOCATION=/var/log/n8n/n8n.log

# Maximum size per log file in MB (default: 16)
N8N_LOG_FILE_SIZE_MAX=50

# Maximum number of log files to keep (default: 100)
N8N_LOG_FILE_COUNT_MAX=30

Output Destinations

The N8N_LOG_OUTPUT variable accepts three values:

• console: Logs go to stdout/stderr (default)
• file: Logs write to the specified file location
• console,file: Logs go to both destinations

For Docker deployments, console is typically preferred because Docker captures stdout and provides its own log management. For direct npm installations, file logging with rotation prevents log loss across restarts.

Docker Compose Configuration

Here’s a complete logging configuration for a Docker Compose deployment:

services:
  n8n:
    image: docker.n8n.io/n8nio/n8n
    environment:
      # Logging Configuration
      - N8N_LOG_LEVEL=warn
      - N8N_LOG_OUTPUT=console

      # If you need file logging inside container
      # - N8N_LOG_OUTPUT=console,file
      # - N8N_LOG_FILE_LOCATION=/home/node/.n8n/logs/n8n.log
      # - N8N_LOG_FILE_SIZE_MAX=50
      # - N8N_LOG_FILE_COUNT_MAX=10

      # Enable metrics endpoint for monitoring
      - N8N_METRICS=true
      - N8N_METRICS_INCLUDE_DEFAULT_METRICS=true

Configuration by Environment

Development Environment

N8N_LOG_LEVEL=debug
N8N_LOG_OUTPUT=console

Verbose logging to console for maximum visibility during workflow development.

Production Environment

N8N_LOG_LEVEL=warn
N8N_LOG_OUTPUT=file
N8N_LOG_FILE_LOCATION=/var/log/n8n/n8n.log
N8N_LOG_FILE_SIZE_MAX=100
N8N_LOG_FILE_COUNT_MAX=14

Warning-level logging to rotated files. Keeps two weeks of logs at 100MB each (1.4GB max).

Temporary Troubleshooting

N8N_LOG_LEVEL=debug
N8N_LOG_OUTPUT=file
N8N_LOG_FILE_LOCATION=/tmp/n8n-debug.log

Debug to a temporary file. Remember to revert after troubleshooting.

Where to Find n8n Logs

Finding your logs depends on how n8n is deployed. Here’s where to look in each scenario.

Docker Deployments

For Docker containers, logs go to stdout by default. Access them with Docker’s log commands.

# View recent logs
docker logs n8n

# Follow logs in real-time
docker logs -f n8n

# View last 100 lines
docker logs --tail 100 n8n

# View logs since specific time
docker logs --since 1h n8n

# View logs with timestamps
docker logs -t n8n

For Docker Compose deployments:

# View logs for n8n service
docker compose logs n8n

# Follow multiple services
docker compose logs -f n8n postgres redis

# View logs for all services
docker compose logs

npm/Direct Installation

When running n8n via npm (npx n8n or n8n start), logs appear in the terminal by default. If you configured file logging, check:

# Default location
~/.n8n/logs/n8n.log

# Or your custom location from N8N_LOG_FILE_LOCATION

n8n Cloud

n8n Cloud doesn’t provide server-level log access. You get:

• Execution logs: Available in the UI for each workflow execution
• Error details: Captured in the execution view when workflows fail
• Activity log: Shows workflow changes and deployments

For deeper debugging on n8n Cloud, you’ll need to add logging within your workflows using Set nodes or external logging services.

Kubernetes Deployments

In Kubernetes, logs flow through the standard kubectl interface:

# View pod logs
kubectl logs -n n8n deployment/n8n

# Follow logs
kubectl logs -f -n n8n deployment/n8n

# View logs from specific container (if multiple)
kubectl logs -n n8n deployment/n8n -c n8n

# View previous container logs (after restart)
kubectl logs -n n8n deployment/n8n --previous

For production Kubernetes deployments, integrate with your cluster’s logging stack (typically Loki, Elasticsearch, or CloudWatch).

Why console.log() Doesn’t Work (And How to Fix It)

This is the single most confusing aspect of n8n debugging. Users add console.log() to their Code nodes, run the workflow manually, and see nothing in the n8n UI.

Understanding the Problem

The issue stems from how n8n handles different execution contexts.

Manual executions (clicking “Test workflow” or “Execute node” in the editor) use WebSocket connections to stream results back to your browser. The browser receives execution output and displays it in the UI. However, console.log() output from Code nodes goes to the server’s stdout, not through the WebSocket.

Production executions (triggered by webhooks, schedules, or the API) run entirely on the server. The CODE_ENABLE_STDOUT environment variable can enable console output for these executions, but it doesn’t affect manual testing.

Solution 1: Return Debug Data in Node Output

The most reliable approach is to include debug information in your node’s return value:

// Instead of console.log(myData)
const debugInfo = {
  inputReceived: $input.all(),
  transformedData: processedResults,
  timestamp: new Date().toISOString()
};

return [
  {
    json: {
      ...yourActualOutput,
      _debug: debugInfo  // Remove this in production
    }
  }
];

This debug data appears in the node’s output panel and execution log, visible in both manual and production executions.

Solution 2: Enable Server-Side Output

For production executions where you need console.log() output in server logs:

# Enable stdout for Code node console.log
CODE_ENABLE_STDOUT=true

# Also set appropriate log level
N8N_LOG_LEVEL=info

After setting this, console.log() output from production executions will appear in your server logs (Docker logs, log files, etc.).

Solution 3: Use the Execution Log

n8n captures substantial execution data automatically. For any execution:

1. Go to Executions in the n8n UI
2. Click on the specific execution
3. Click any node to see its input/output data
4. Check the Error tab for failure details

This built-in logging often provides the information you need without custom console statements.

Solution 4: Python Code Nodes

For Python Code nodes, use print() instead of console.log():

data = _("Previous Node").all()
print(f"Received {len(data)} items")
print(type(data[0].json))

# Your processing logic here
return processed_data

Python print statements follow the same rules as JavaScript console.log: they require CODE_ENABLE_STDOUT=true for production executions and won’t appear in the UI for manual executions.

Debugging Browser Console

For manual executions, check your browser’s developer console (F12). n8n sends WebSocket messages that may include logging information. Look for:

1. Open browser DevTools
2. Go to the Network tab
3. Filter for WebSocket connections (/rest/push)
4. Examine message payloads for sendConsoleMessage events

If these messages aren’t appearing, WebSocket connectivity issues (common with certain reverse proxy configurations) may be blocking the output.

Setting Up n8n Monitoring for Production

Logging tells you what happened. Monitoring tells you what’s happening now and alerts you before problems become outages.

Health Endpoints

n8n provides health check endpoints for monitoring systems. Enable them with:

N8N_METRICS=true

Available endpoints:

Endpoint	Purpose	Response
/healthz	Basic health check	200 if n8n is running
/healthz/readiness	Readiness probe	200 if DB connected and migrated
/metrics	Prometheus metrics	Detailed system metrics

The /healthz endpoint confirms n8n is reachable but doesn’t verify database connectivity. Use /healthz/readiness for Kubernetes readiness probes or load balancer health checks that should only route traffic to fully operational instances.

Prometheus Metrics

The /metrics endpoint exposes detailed metrics in Prometheus format. Enable comprehensive metrics with:

N8N_METRICS=true
N8N_METRICS_INCLUDE_DEFAULT_METRICS=true
N8N_METRICS_INCLUDE_QUEUE_METRICS=true

Key metrics to monitor:

# Workflow execution counts
n8n_workflow_success_total
n8n_workflow_failed_total

# Queue metrics (queue mode only)
n8n_scaling_mode_queue_jobs_waiting
n8n_scaling_mode_queue_jobs_active
n8n_scaling_mode_queue_jobs_completed
n8n_scaling_mode_queue_jobs_failed

# System metrics
process_cpu_seconds_total
process_resident_memory_bytes
nodejs_heap_size_total_bytes

Recommended Monitoring Stack

For production n8n deployments, consider this monitoring architecture:

Prometheus scrapes the /metrics endpoint on a schedule (typically every 15-30 seconds) and stores time-series data. Configure a scrape target:

# prometheus.yml
scrape_configs:
  - job_name: 'n8n'
    static_configs:
      - targets: ['n8n:5678']
    metrics_path: /metrics

Grafana connects to Prometheus for visualization. Build dashboards showing:

• Workflow success/failure rates over time
• Queue depth and processing latency
• Memory and CPU usage trends
• Error rate spikes

Grafana Loki aggregates logs from all n8n containers. Use Promtail as the log shipper:

# promtail-config.yaml
scrape_configs:
  - job_name: n8n
    docker_sd_configs:
      - host: unix:///var/run/docker.sock
    relabel_configs:
      - source_labels: ['__meta_docker_container_name']
        regex: '/n8n.*'
        action: keep

Setting Up Alerts

Configure alerts in Prometheus or Grafana for:

• High error rate: rate(n8n_workflow_failed_total[5m]) > 0.1
• Queue backlog: n8n_scaling_mode_queue_jobs_waiting > 100
• Memory pressure: nodejs_heap_size_used_bytes / nodejs_heap_size_total_bytes > 0.9
• Instance down: No metrics received for 5 minutes

Building a Workflow Failure Alerting System

Server logs and metrics are essential, but you also want immediate notification when specific workflows fail. n8n’s Error Trigger node enables this.

Error Trigger Workflow

Create a dedicated workflow that triggers whenever another workflow fails:

1. Create a new workflow named “Error Handler”
2. Add an Error Trigger node as the start
3. Add filtering logic if you only want alerts for specific workflows
4. Connect to your notification channel (Slack, email, PagerDuty)

The Error Trigger receives this data when a workflow fails:

{
  "execution": {
    "id": "12345",
    "url": "https://your-n8n.com/execution/12345",
    "retryOf": null,
    "error": {
      "message": "The API returned an error",
      "stack": "Error: The API returned..."
    },
    "lastNodeExecuted": "HTTP Request",
    "mode": "trigger"
  },
  "workflow": {
    "id": "567",
    "name": "Customer Sync Workflow"
  }
}

Example: Slack Alert Workflow

Error Trigger
    ↓
IF Node (filter critical workflows)
    ↓
Slack Node (send alert)

Configure the Slack message:

Workflow Failed: {{ $json.workflow.name }}

Error: {{ $json.execution.error.message }}
Node: {{ $json.execution.lastNodeExecuted }}

View execution: {{ $json.execution.url }}

Assigning Error Workflows

For Error Trigger to work, you must assign the error handling workflow to your production workflows:

1. Open the workflow you want to monitor
2. Go to Settings (gear icon)
3. Under Error Workflow, select your error handler
4. Save the workflow

This assignment is per-workflow. For comprehensive coverage, assign the error handler to all production workflows.

For more on handling errors gracefully within workflows, see our workflow best practices guide.

Logging in Distributed n8n (Queue Mode)

When running n8n in queue mode with separate main instances and workers, logging requires additional consideration.

The Challenge

In queue mode, you have multiple processes:

• Main instance: Handles UI, webhooks, and job queuing
• Workers: Execute workflows independently
• Webhook processor (optional): Dedicated webhook handling

Each process generates its own logs. A single workflow execution might span logs from the main instance (job creation) and a worker (job execution). Correlating these logs requires the execution ID.

Centralized Logging Setup

For distributed deployments, centralize logs using a log aggregation system. A common stack:

Promtail ships logs from each container to Loki:

# docker-compose.yml addition
promtail:
  image: grafana/promtail:latest
  volumes:
    - /var/run/docker.sock:/var/run/docker.sock
    - ./promtail-config.yaml:/etc/promtail/config.yml
  command: -config.file=/etc/promtail/config.yml

Loki stores and indexes logs:

loki:
  image: grafana/loki:latest
  ports:
    - "3100:3100"
  volumes:
    - loki_data:/loki

Grafana queries Loki for log visualization and search.

Log Correlation

Include execution IDs in your log queries to trace a single execution across processes:

{job="n8n"} |= "executionId=12345"

n8n includes execution context in log messages when using structured logging. The key identifiers:

• executionId: Unique identifier for each workflow run
• workflowId: The workflow being executed
• workerId: Which worker processed the job (queue mode)

Docker Logging Drivers

For simpler setups, Docker’s logging drivers can forward logs directly to external systems:

# docker-compose.yml
services:
  n8n:
    logging:
      driver: "gelf"
      options:
        gelf-address: "udp://logstash:12201"

Supported drivers include gelf (Graylog), fluentd, awslogs, and gcplogs.

Solving Common n8n Logging Problems

Problem: Logs Not Appearing

Symptoms: You set N8N_LOG_LEVEL=debug but still see no logs.

Solutions:

1. Check N8N_LOG_OUTPUT: If set to file only, logs won’t appear in console
2. Verify environment variables are applied: Restart n8n after changing variables
3. Check file permissions: If logging to file, ensure n8n can write to that location
4. Docker volume mounts: For file logging in Docker, mount the log directory as a volume

volumes:
  - ./logs:/home/node/.n8n/logs

Problem: Logs Too Verbose or Too Quiet

Symptoms: Either drowning in log data or seeing nothing useful.

Solutions:

For verbose logs:

• Reduce to N8N_LOG_LEVEL=warn for production
• Use log filtering (grep, Loki queries) to find relevant entries
• Consider log sampling for extremely high-volume deployments

For quiet logs:

• Increase to N8N_LOG_LEVEL=info or debug temporarily
• Check that N8N_LOG_OUTPUT includes your intended destination
• Verify workflows are actually executing (check execution list)

Problem: Disk Filling Up with Logs

Symptoms: Server disk space depleted, n8n stops working.

Solutions:

Configure log rotation properly:

# Limit each log file to 50MB
N8N_LOG_FILE_SIZE_MAX=50

# Keep only 10 log files (500MB max total)
N8N_LOG_FILE_COUNT_MAX=10

For Docker deployments, configure Docker’s log rotation:

// /etc/docker/daemon.json
{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "100m",
    "max-file": "3"
  }
}

Also consider execution data pruning to control database growth.

Problem: Can’t Correlate Logs to Specific Executions

Symptoms: Logs show errors but you can’t find which execution failed.

Solutions:

1. Use execution URL from Error Trigger: The error workflow provides direct links
2. Search logs by timestamp: Note when the execution occurred, search that time window
3. Include execution ID in custom logging: In Code nodes, reference $execution.id
4. Use structured log queries: {job="n8n"} | json | executionId="12345"

Problem: WebSocket Issues Blocking Debug Output

Symptoms: Manual executions work but you never see console.log output in the UI.

Solutions:

1. Check reverse proxy WebSocket configuration (nginx, Traefik)
2. Verify /rest/push WebSocket endpoint is accessible
3. Check browser console for WebSocket errors
4. Test with direct n8n access (bypassing reverse proxy) to isolate the issue

For reverse proxy configuration, ensure WebSocket upgrade headers are passed:

# nginx configuration
location / {
    proxy_pass http://n8n:5678;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
}

Enterprise Logging Patterns

Log Streaming (Enterprise Feature)

n8n’s Enterprise tier includes log streaming, which sends logs in real-time to external destinations. This enables:

• Integration with SIEM tools (Splunk, Datadog, etc.)
• Real-time log analysis and alerting
• Compliance and audit log retention

Configure log streaming through the n8n admin interface or API.

Structured Logging Best Practices

For teams building custom integrations or analyzing logs at scale:

Include consistent identifiers:

// In Code nodes, add context to custom logging
const logContext = {
  workflowId: $workflow.id,
  workflowName: $workflow.name,
  executionId: $execution.id,
  nodeId: $node.id
};

// Include in any external logging calls
await $http.request({
  method: 'POST',
  url: 'https://logging-service/api/log',
  body: {
    level: 'info',
    message: 'Processing completed',
    context: logContext,
    data: { itemsProcessed: items.length }
  }
});

Use node types for searchability:

When logging, reference node types (like n8n-nodes-base.httpRequest) rather than custom node names. Node types are consistent across workflows; names vary.

Separate business logs from system logs:

System logs (n8n’s built-in logging) track infrastructure health. Business logs (custom logging in workflows) track your specific operations. Keep them in separate indexes or streams for easier analysis.

When to Get Professional Help

Logging and monitoring infrastructure can become complex, especially for:

• High-volume production deployments processing thousands of executions daily
• Distributed queue mode setups with multiple workers
• Compliance requirements demanding audit trails and log retention
• Integration with existing enterprise monitoring stacks

Our n8n support and maintenance service includes proactive monitoring setup, alerting configuration, and ongoing log analysis. For one-time infrastructure setup, our self-hosted setup service ensures your logging foundation is production-ready from day one.

You can also use our free workflow debugger to analyze specific error messages and get actionable fixes.

Frequently Asked Questions

Why doesn’t console.log() show in the n8n UI when I run my workflow?

When you manually execute a workflow in the n8n editor, console.log() output goes to the server’s stdout, not to your browser. The n8n UI receives execution results via WebSocket, but standard console output isn’t included in that channel.

To see debug output in the UI, return the data as part of your node’s output instead of using console.log. For production executions, set CODE_ENABLE_STDOUT=true to capture console output in server logs. Check your browser’s developer console for WebSocket connectivity issues if you expect output but see nothing.

What log level should I use in production?

warn is recommended for most production deployments. It captures errors and potential issues without the volume of info or debug levels.

Reserve debug level for active troubleshooting sessions. Debug logging is extremely verbose and can generate gigabytes of data quickly, impacting disk space and potentially performance. When troubleshooting, enable debug temporarily, capture the relevant logs, then revert to warn.

For critical systems where you need maximum visibility, info provides a middle ground but expect higher log volume.

How do I see logs for a specific workflow execution?

In the n8n UI: Go to Executions, find the execution by timestamp or status, click to open it. Each node shows its input/output data. Failed nodes display error details.

In server logs: Search by execution ID. If you know the execution ID (visible in the UI or from Error Trigger), grep or query for it: grep "executionId=12345" /var/log/n8n/n8n.log

For correlation: n8n includes executionId, workflowId, and other context in structured log entries. Use these fields to filter logs in aggregation systems like Loki or Elasticsearch.

Can I send n8n logs to an external monitoring system?

Yes, through several methods:

Built-in options: Enterprise tier includes log streaming to external destinations. The /metrics endpoint works with Prometheus and compatible systems.

DIY approaches: Use log shipping tools like Promtail (for Loki), Filebeat (for Elasticsearch), or Fluentd. Configure Docker logging drivers to send directly to Graylog, AWS CloudWatch, or GCP Logging.

Workflow-based logging: For business-level logging, add HTTP Request nodes in your workflows to send custom events to your logging service.

My n8n log file is getting huge. How do I manage it?

Configure log rotation with these environment variables:

# Maximum size per log file (MB)
N8N_LOG_FILE_SIZE_MAX=50

# Maximum number of log files to keep
N8N_LOG_FILE_COUNT_MAX=10

This configuration keeps at most 500MB of logs (10 files x 50MB each). Older files are deleted automatically when limits are reached.

For Docker deployments, also configure Docker’s log rotation in /etc/docker/daemon.json to prevent container logs from growing unbounded.

Additionally, ensure you’re not running at debug level in production. Debug logging generates far more data than warn or info levels.