Learn n8n - Audit, Monitoring & Observability

#Introduction

In episode 12 you secured credentials and locked down UI and API access. Now an equally important question arises: how do we know everything is running healthy? An unmonitored instance is a black box — you only find out a workflow failed after a user complains by email.

Episode 13 covers Audit, Monitoring & Observability. The roadmap: tracking workflow executions and node logs, integrating external monitoring like Prometheus, Grafana, and ELK, as well as applying alerts and notifications for every failure.

#Tracking Workflow Executions

Before pulling telemetry outward, n8n already stores execution data internally. Every run is recorded in Execution History with complete metadata: success or error status, start and end timestamps, duration, execution mode (manual, trigger, test), plus per-node output for debugging.

The storage policy for execution data can be fully controlled via environment variables — important because keeping all data long-term eats up database space:

EXECUTIONS_DATA_PRUNE=true
EXECUTIONS_DATA_MAX_AGE=168
EXECUTIONS_DATA_SAVE_ON_SUCCESS=all
EXECUTIONS_DATA_SAVE_ON_ERROR=all
EXECUTIONS_DATA_SAVE_ON_PROGRESS=false
EXECUTIONS_DATA_SAVE_ON_MANUAL_EXECUTION=true

EXECUTIONS_DATA_MAX_AGE is measured in hours — a value of 168 means execution data is kept for one week. This combination provides enough data to investigate incidents without piling up the database for years.

#Logging: Node Logs & Structured Output

For events below the execution surface — startup, authentication, internal errors — n8n writes application logs. Level and destination can be configured:

N8N_LOG_LEVEL=info
N8N_LOG_OUTPUT=console,file
N8N_LOG_FORMAT=json
N8N_LOG_FILE_LOCATION=/logs/n8n.log

With N8N_LOG_FORMAT=json, every log line becomes a JSON object containing timestamp, level, message, and metadata. This format makes parsing by automated tools easy — the basis for the ELK integration we'll discuss. When debugging, you can lower N8N_LOG_LEVEL to debug to see details, then raise it back to info in production.

#Metrics with Prometheus

To see instance health from afar, n8n exposes a Prometheus /metrics endpoint. This endpoint is off by default and is enabled with N8N_METRICS=true.

N8N_METRICS=true
N8N_METRICS_INCLUDE_QUEUE_METRICS=true
N8N_METRICS_INCLUDE_WEBHOOK_METRICS=true
N8N_METRICS_INCLUDE_WORKFLOW_INFO=true

Available metrics include the number of executions, number of active workflows, per-node metrics, webhook request duration histograms (n8n_webhook_request_duration_seconds), as well as queue metrics when using queue mode. Both main and workers can expose the same endpoint.

Then configure Prometheus to pull data periodically:

scrape_configs:
  - job_name: n8n
    static_configs:
      - targets: ["n8n-main:5678"]
    metrics_path: /metrics
    scrape_interval: 30s

#Visualization with Grafana

Metrics data in Prometheus only becomes useful when visualized. Grafana connects to Prometheus as a data source and displays panels like:

• Number of executions per hour with a breakdown of success and error status.
• Average duration of the slowest workflow executions.
• Redis queue depth (queue length) when using queue mode.
• Cache hit ratio and Node.js metrics like process memory.

A complete observability flow: n8n exposes /metrics → Prometheus stores time series → Grafana draws dashboards → Grafana alert rules trigger notifications when metrics cross thresholds.

#Streaming Logs to ELK

Metrics give numbers; logs give context. To trace "why" an execution failed, centralized logs in the ELK stack (Elasticsearch, Logstash, Kibana) are far more convenient than logging into each server. The lightest pattern: Filebeat reads the n8n log file, sends it to Elasticsearch, and you investigate in Kibana.

filebeat.inputs:
  - type: filestream
    id: n8n-logs
    paths:
      - /logs/n8n.log
 
output.elasticsearch:
  hosts: ["https://elasticsearch:9200"]
  username: "filebeat_writer"
  password: "${FILEBEAT_PASSWORD}"

Since the log format is already JSON, Kibana can directly index fields like level, workflowId, and message without additional parsing. If you need transformation in the middle, insert Logstash as an intermediary — same principle, one extra stage for enrichment.

#Alerts & Notifications for Failures

Observability isn't complete without proactive notifications. Two main approaches:

1. The error workflow from episode 7 — a dedicated path that catches workflow failures. On this path, add a node sending a message to Slack, Telegram, or the team's email. This is the first and most contextual notification.
2. Alert rules in monitoring tools — for example a Prometheus/Grafana alert when the execution failure rate rises above 5 percent in 15 minutes, or when a worker stops sending heartbeats.

n8n execution error
  -> Error Workflow (Slack #alerts, email on-call)
  -> Prometheus alert: error_rate > 5% dalam 15 menit
  -> Grafana notify channel -> PagerDuty / Telegram

Combining both covers two scenarios: a single workflow failure needing fast action, and systemic degradation that must be detected before it has a broad impact.

#Health Check Endpoints

For automatic monitoring by orchestrators or load balancers, n8n provides status endpoints: /healthz for basic liveness and /healthz/readiness for readiness to serve traffic.

curl -s http://localhost:5678/healthz
curl -s http://localhost:5678/healthz/readiness

In queue mode, worker health checks are off by default and need to be enabled with QUEUE_HEALTH_CHECK_ACTIVE=true. Load balancers or Kubernetes probes can use these endpoints to remove unhealthy nodes from rotation.

#Closing

Episode 13 gave you three layers of visibility: execution data inside n8n for per-workflow debugging, Prometheus metrics visualized in Grafana for instance health, and logs centralized to ELK for deep investigation. Plus alerts from error workflows and monitoring tools, every failure is now an event that is visible, measurable, and actionable.

Key takeaways:

• Execution history stores complete metadata for every run; control retention with EXECUTIONS_DATA_PRUNE and EXECUTIONS_DATA_MAX_AGE.
• N8N_METRICS=true turns on the /metrics endpoint ready for Prometheus and Grafana.
• JSON logs (N8N_LOG_FORMAT=json) are the basis for ELK integration without manual parsing.
• Layered alerts — error workflows for specific failures, alert rules for systemic degradation.
• Health checks /healthz and /healthz/readiness keep orchestrators always using healthy nodes.

In the next episode we enter the organizational side: Governance & Multi-user Collaboration — managing user access and role-based permissions, sharing workflows, credentials, and folders, and maintaining change control and audit trails. See you there!