Monitor n8n Like a Pro – Healthchecks, Queues & Error Alerts

n8n, a workflow automation tool, can silently fail without warning, leading to missed data or disrupted operations. This article explains how to monitor n8n effectively to prevent such issues, ensure uptime, and optimize performance. You’ll learn about:

• Setting up healthchecks (/healthz, /healthz/readiness, /metrics) to monitor service availability, database connectivity, and performance metrics.
• Using Error Triggers to catch and alert you about workflow failures in real time.
• Configuring queue mode with Redis for scalable workflow execution.
• Leveraging tools like Prometheus and Grafana for performance tracking and visualization.

Setting Up n8n Healthchecks

By default, healthchecks in n8n are turned off. To activate them, you’ll need to add two environment variables: QUEUE_HEALTH_CHECK_ACTIVE=true and N8N_METRICS=true. Below, you’ll find details on configuring these endpoints and linking them with VPS.us monitoring tools.

How to Configure Healthcheck Endpoints

Once healthchecks are enabled, n8n offers three monitoring endpoints:

• /healthz: This endpoint confirms that n8n is running by returning a 200 OK status. However, it doesn’t verify if workflows are being executed properly.
• /healthz/readiness: This endpoint checks both service availability and database connectivity. It’s ideal for uptime monitoring since it ensures n8n is fully functional and ready to handle workflows. A 200 OK here means the database connection is active and migrations are complete.
• /metrics: This endpoint provides performance statistics in Prometheus format. Metrics include CPU usage, memory consumption, event loop lag, and queue-related stats like n8n_scaling_mode_queue_jobs_waiting. To enable queue metrics, set N8N_METRICS_INCLUDE_QUEUE_METRICS=true, and adjust the refresh interval with N8N_METRICS_QUEUE_METRICS_INTERVAL (default is 20 seconds).

Healthcheck Endpoint Comparison

Managing n8n Queues with Redis

As your workflows grow and start processing larger volumes of tasks, a single n8n instance can quickly become overwhelmed. This is where Queue mode with Redis comes in – it separates the user interface from workflow execution, allowing you to scale your system horizontally by adding more workers while keeping the interface responsive.

How to Enable Queue Mode with Redis

Queue mode relies on four key components working together:

• Main process: Manages the UI and orchestrates workflows.
• Redis: Acts as the message broker.
• Workers: Execute workflows in parallel.
• PostgreSQL: Stores workflow states and credentials.

For moderate workloads, you can run all these components on a single VPS.us KVM2-US instance for $20/month (2 vCores and 2 GB RAM). As your needs grow, you can distribute these components across multiple servers for better performance.

To enable queue mode, set EXECUTIONS_MODE=queue on both the main instance and all worker nodes. Configure Redis by pointing to its host and port using QUEUE_BULL_REDIS_HOST and QUEUE_BULL_REDIS_PORT (default: 6379). It’s crucial that all nodes share the same N8N_ENCRYPTION_KEY to decrypt credentials; mismatched keys will lead to silent failures.

Launch workers using the n8n worker command. Each worker can handle up to 10 concurrent jobs. For a quick setup, use Docker Compose:

docker compose up -d --scale worker=3

This will spin up three worker containers instantly, allowing for seamless scaling.

For added reliability in production, modify the Redis configuration by setting appendonly yes in redis.conf. This ensures that queued jobs are preserved even if your VPS crashes.

To prevent the main process from freezing during heavy debugging, enable OFFLOAD_MANUAL_EXECUTIONS_TO_WORKERS=true. This setting shifts manual test runs to workers, ensuring the UI remains smooth and responsive.

Once queue mode is configured, the next step is to monitor performance metrics to keep your system running efficiently.

Tracking Queue Metrics

Enable metrics tracking by setting N8N_METRICS=true and N8N_METRICS_INCLUDE_QUEUE_METRICS=true. This exposes Prometheus-compatible metrics at the /metrics endpoint. The main instance will report queue-specific data, while both the main and worker nodes will provide process-level metrics.

A key metric to monitor is n8n_scaling_mode_queue_jobs_waiting, which shows how many jobs are queued in Redis. If this number keeps increasing while n8n_scaling_mode_queue_jobs_active remains flat, it’s a clear sign that you need more workers or are facing bottlenecks in PostgreSQL or external APIs.

Use Prometheus’s rate functions to catch issues early. For example, querying rate(n8n_scaling_mode_queue_jobs_failed[5m]) can help you identify sudden spikes in job failures. Pair this with a Redis Exporter to keep an eye on memory usage and connected clients, as bottlenecks often arise in Redis or PostgreSQL rather than n8n itself.

The metric refresh interval defaults to 20 seconds and is adjustable via N8N_METRICS_QUEUE_METRICS_INTERVAL. With VPS.us AlwaysOn monitoring, you can continuously poll these endpoints and receive alerts before users experience any slowdowns. This proactive approach ensures your n8n workflows remain responsive and scalable, even under heavy loads.

Setting Up Error Alerts and Triggers

After configuring queue metrics, the next step is enabling real-time alerts. Without these, workflow failures might go unnoticed for hours – or even days. The Error Trigger node acts as your first line of defense. It’s a specialized starting point that automatically kicks off a dedicated “error workflow” whenever a production workflow encounters an issue.

Configuring Error and Success Triggers

To set up error alerts, start by creating an error workflow using an Error Trigger node. Link this to the monitored workflow in its Settings and save both workflows to activate the connection.

The Error Trigger only responds to production executions – like webhooks, schedules, or API calls – so you won’t get bombarded with alerts during testing. When a failure occurs, the trigger provides a JSON payload with key details like:

• {{ $json.workflow.name }}
• {{ $json.execution.error.message }}
• {{ $json.execution.url }}
• {{ $json.lastNodeExecuted }}

This data can be routed to a Slack, Discord, or Email node for instant notifications. For instance, a Slack alert might look like this:
“Workflow ‘Customer Onboarding’ failed at node ‘Send Welcome Email’ with error: ‘SMTP timeout’. View execution: https://your-n8n.vps.us/execution/abc123.”
This level of detail makes troubleshooting much faster.

You can also force errors based on custom logic. For example, use Stop and Error after an IF node to trigger a failure if {{ $json.customer_email === null }}. This setup not only catches errors but also allows for tailored notifications.

To handle “silent failures” (workflows that don’t run at all), create a watchdog system using a Schedule Trigger that runs every 24 hours. Pair it with an n8n node (resource: execution, operation: getAll) to check recent execution history. If a critical workflow hasn’t run successfully within the expected timeframe, route the result through an IF node and send an alert. This setup can catch issues like disabled schedules or broken webhooks that the Error Trigger wouldn’t detect.

For added assurance, you can build a Success Trigger to monitor successful executions. Send daily summaries to verify workflow health – especially useful in compliance-heavy scenarios.

Building Custom Monitoring Workflows

Once basic alerts are in place, you can refine your error workflows for smarter handling. Use a Switch node to categorize errors (e.g., API timeouts vs. data validation issues) so that critical problems get immediate attention, while less urgent ones can be reviewed later.

To avoid alert fatigue, add throttling logic. For example, use an IF node to check a “cooldown” flag stored in a database or static variable. If the same workflow triggered an alert within the last 10 minutes, skip the notification. This is especially useful in high-volume environments where a single misconfigured API could trigger hundreds of alerts.

For temporary issues like 503 errors, implement retries with exponential backoff. If retries fail, log the error immediately for review.

To maintain a historical record of failures, connect your Error Trigger to a Google Sheets or Postgres node. This is critical if n8n’s internal logs are cleared after 30 days, as it provides a long-term view for spotting trends or justifying infrastructure changes.

In high-traffic setups, consider building an aggregation workflow. Use the n8n node to query the API hourly, grouping errors by workflow name. Instead of sending individual alerts for each failure, send a consolidated Slack message summarizing the issues. Include a link to a Grafana dashboard for deeper insights. This approach reduces noise while keeping you informed about overall system health.

Visualizing Metrics with Grafana

Once you’ve set up error workflows, it’s time to add visual analytics with Grafana. Grafana takes raw metrics and turns them into dynamic, real-time dashboards. These dashboards give you a clear picture of what’s happening inside your n8n instance – whether it’s CPU spikes or growing queue backlogs. Instead of digging through logs or running manual checks, you’ll have a centralized view of system health and workflow performance.

Installing Grafana on VPS.us

To run Grafana smoothly, you’ll need at least 512 MB of RAM and 1 CPU core. However, opting for a KVM8-US plan (8 vCores, 8 GB RAM, 80 GB NVMe) ensures you have enough resources to run Grafana alongside n8n, Prometheus, and Redis without any hiccups. Using Docker Compose is the easiest way to deploy Grafana as part of your monitoring stack.

Add this configuration to your existing docker-compose.yml:

grafana:
  image: grafana/grafana:latest
  container_name: grafana
  ports:
    - "3000:3000"
  volumes:
    - grafana-storage:/var/lib/grafana
  environment:
    - GF_SECURITY_ADMIN_PASSWORD=your_secure_password
  restart: unless-stopped

Start Grafana with docker-compose up -d. Once running, access it at http://your-vps-ip:3000. The default login is admin / admin, but you’ll be prompted to change it immediately. For a production setup, bind Grafana to localhost:3000and use Nginx as a reverse proxy with SSL. Ensure Nginx is configured to support WebSocket connections for Grafana Live.

To enable metrics in n8n, set N8N_METRICS and N8N_METRICS_INCLUDE_QUEUE_METRICS to true in your n8n container. Restart the container and confirm that metrics are being exposed by visiting http://your-n8n-instance:5678/metrics. You’ll find Prometheus metrics here, including event loop latencies (P50, P90, P99) and garbage collection durations.

With Grafana connected to n8n’s metrics, you’re ready to build dashboards.

Importing n8n Dashboards into Grafana

Pre-configured dashboard templates make it easy to monitor key metrics. Start by adding data sources in Grafana:

• Prometheus: Tracks system health (CPU, memory, event loop lag).
• PostgreSQL: Analyzes workflow performance (success rates, execution times). Use a read-only database user to prevent accidental changes. You can create one with the following command:
  GRANT SELECT ON ALL TABLES IN SCHEMA public TO grafana_reader;

Next, update your prometheus.yml to scrape metrics from n8n:

scrape_configs:
  - job_name: 'n8n'
    scrape_interval: 15s
    static_configs:
      - targets: ['n8n:5678']
    metrics_path: '/metrics'

A 15-second scrape interval strikes a balance between detail and storage efficiency. Restart Prometheus and check the Prometheus UI at http://your-vps-ip:9090/targets to ensure the target is active.

To import dashboards, go to Dashboards → Import in Grafana. Use the following Dashboard IDs:

• 24474: System Health Overview
• 24475: Workflow & Execution Analytics

Grafana will ask you to assign the appropriate data sources (Prometheus or PostgreSQL). Once imported, you’ll see panels displaying metrics like n8n_scaling_mode_queue_jobs_waiting (jobs waiting in Redis) and n8n_nodejs_eventloop_lag_p90_seconds (90th percentile event loop lag). For instance, if the queue depth grows consistently, it’s a sign you might need more worker nodes. Event loop lag spikes could indicate heavy synchronous processing that’s slowing down other workflows.

For high-traffic environments, consider adding panels for webhook request rates and HTTP 4xx/5xx errors from your Nginx access logs. This helps identify issues at the edge before they impact n8n. You can also set up alerts for critical thresholds – like more than 50 jobs waiting for over 10 minutes or a success rate dropping below 95%. These alerts can be routed to Slack or PagerDuty, ensuring you’re notified before small issues become major problems. This creates a seamless feedback loop: errors trigger workflows, metrics feed into Grafana, and alerts keep you informed of potential risks.

Using Dead-Letter Queues and Incident Workflows

When a workflow fails, capturing its error and routing it for review is essential to keep the execution queue running smoothly. Dead-letter queues (DLQs) are designed to hold jobs that can’t be retried – like those with invalid data or fatal 404 errors. Unlike standard execution logs, which may be temporary, a DLQ offers a permanent record for analyzing patterns and identifying root causes.

Routing Failed Jobs to Dead-Letter Queues

Since n8n doesn’t come with a built-in DLQ node, you can use the Error Trigger node to catch errors globally. This node acts as a universal safety net, firing whenever a linked workflow fails. Start by creating a new workflow named “Error Handler” with the Error Trigger as the first node. Then, link this error handler to your production workflows through the “Error Workflow” dropdown in each workflow’s settings.

Once an error is captured, route its details to a storage system like Redis, PostgreSQL, or even Google Sheets. Key details to store include the workflow name, execution ID, failed node, error message, and execution URL. For instance, if you’re using PostgreSQL, set up a table with columns for these fields and use an HTTP Request or Postgres node to log the data.

You can also handle errors inline by using node error outputs (the red connectors). Enabling “Continue on Fail” allows errors to flow to subsequent nodes without stopping the workflow entirely. This approach is helpful for handling specific node failures while bypassing the global error handler.

If you’re running workflows in queue mode with Redis, keep an eye on the n8n_scaling_mode_queue_jobs_failedmetric in Prometheus. This metric tracks jobs that have entered a failed state in the Redis-backed Bull queue. A steady increase in this number could indicate that your error workflows aren’t resolving issues quickly enough or that the root causes of failures need attention.

With errors captured and logged, the next step is creating workflows to address and resolve them.

Creating Incident Response Workflows

Incident response workflows help determine how to handle various errors. Use a Switch node to route errors based on their severity. For example, send 429 and 5xx errors into a retry loop, while routing 400 and 404 errors straight to the DLQ.

In your retry loop, add a Wait node with delays of 10, 30, and 60 seconds between attempts. This prevents overwhelming external APIs. If the job succeeds during a retry, log it as a recovered error. If it fails after three retries, move it to the DLQ and notify your team via Slack or email.

For critical errors that happen outside business hours, route them to PagerDuty. A Switch node can check the current time and escalate urgent issues accordingly. This ensures your team isn’t bombarded with notifications during the day but can still respond promptly to high-priority problems.

You can also automate fixes for recurring failure patterns. For instance, if a workflow frequently fails due to high CPU usage, you could trigger a recovery script to restart the affected service. For idempotent tasks – like sending a webhook or updating a database record – automated retries are a safe and effective solution. These automated responses can help refine your overall workflow strategy.

Identifying Failure Patterns

Once your incident workflows are active, analyzing error trends becomes crucial. Use Grafana to create visualizations of “top offender” workflows by pulling failure counts from your n8n PostgreSQL database. Query the execution_entitytable and group failures by workflowId to see which workflows fail the most, helping you prioritize fixes.

In Prometheus, use the metric rate(n8n_scaling_mode_queue_jobs_failed[5m]) to monitor spikes in failures. Set up alerts for situations where failures exceed one per second over five minutes. This reduces noise by focusing on trends rather than isolated incidents.

For silent failures – where workflows don’t trigger because a webhook stops sending data – set up a “watchdog” workflow. Schedule this to run hourly, using the n8n API to check if critical workflows have executed in the last 24 hours. If they haven’t, send an alert. This catches problems that wouldn’t appear in error logs because the workflow never started.

These techniques can feed directly into your Grafana dashboards, offering insights for continuous improvement.

Conclusion: Monitoring n8n on VPS.us

Key Monitoring Strategies Recap

Keeping n8n running smoothly involves layering multiple monitoring tools and strategies across your automation setup. Start with health checks like /healthz/readiness to verify uptime and database connections. Pair this with Error Trigger nodes to catch and alert your team about workflow failures. Notifications sent via Slack or email, complete with execution IDs, ensure quick troubleshooting.

If you’re scaling with Redis for queue management, monitoring queue metrics becomes critical. For example, setting up alerts with expressions like rate(n8n_scaling_mode_queue_jobs_failed[5m]) > 1 can help identify recurring issues while avoiding noise from one-off spikes. Watchdog workflows are another safeguard, checking whether essential automations have run within a set timeframe, like the last 24 hours, to catch silent failures.

To visualize it all, Grafana is a game-changer. Use it to graph queue depth alongside VPS-level metrics like CPU, RAM, and disk usage. Spotting trends – like resource usage consistently exceeding 80% – can help you decide when to expand capacity before performance takes a hit.