Monitoring: Logs, Healthchecks, Prometheus/Grafana

Anyone who self-hosts an n8n instance needs three building blocks for reliable operation: meaningful logs for troubleshooting, a healthcheck endpoint for uptime monitoring, and Prometheus metrics for deeper insight into queues, webhooks, and forms. n8n already includes all three building blocks, they just need to be enabled and connected via environment variables. As of: July 2026.

Configuring log level and log output

n8n uses the winston logging library and configures the log output according to the n8n documentation on logging via environment variables. For everyday use, two settings are enough.

• N8N_LOG_LEVEL: controls the verbosity. From low to high, silent, error, warn, info and debug are available, the default is info. silent outputs nothing, debug provides the most detailed diagnostic information and is mainly suited for targeted troubleshooting.
• N8N_LOG_OUTPUT: determines where logging goes, console or file, also combined as console,file. The default is console.
• N8N_LOG_FILE_LOCATION: path of the log file, when file is active. The default is <n8n folder>/logs/n8n.log.
• N8N_LOG_FILE_SIZE_MAX: maximum size per log file in MB, default 16 MB.
• N8N_LOG_FILE_COUNT_MAX: maximum number of retained log files, default 100. With multiple workers, this value should be set deliberately so the rotation matches the available storage.

For production, info is generally sufficient, debug remains a temporary measure because it noticeably writes more data and fills up the log files faster.

Healthcheck endpoints for uptime monitoring

According to the n8n documentation on monitoring n8n provides two health endpoints suited for external uptime checks. The /healthz endpoint merely reports whether the instance is reachable, an HTTP 200 says nothing about the database status. The /healthz/readiness endpoint goes further: it only returns 200 once the database is connected and migrated, meaning the instance is actually ready to process requests. The path can be adjusted via the N8N_ENDPOINT_HEALTH variable, for example when a reverse proxy expects a different health path.

On the main server, the health endpoint is always active. On worker instances in queue mode, however, it is disabled by default and must be enabled via QUEUE_HEALTH_CHECK_ACTIVE=true if a load balancer or orchestrator should also check the workers.

Exporting Prometheus metrics

For more detailed operational data, n8n provides a /metrics endpoint via the prom-client library. It is disabled by default and is enabled with N8N_METRICS=true, on both main and worker instances. Important for operation: the endpoint should not be publicly reachable, but only for internal systems that consume the Prometheus data, since it exposes operational details of the instance.

Which metrics and labels are specifically output is controlled by the N8N_METRICS_INCLUDE_*-variables. For scaling setups in queue mode, N8N_METRICS_INCLUDE_QUEUE_METRICS=true provides metrics such as n8n_scaling_mode_queue_jobs_active, _completed, _failed and _waiting, the refresh rate can be adjusted via N8N_METRICS_QUEUE_METRICS_INTERVAL. Since n8n 2.28.0, webhook and form runtimes can additionally be captured: N8N_METRICS_INCLUDE_WEBHOOK_METRICS enables the histogram n8n_webhook_request_duration_seconds, N8N_METRICS_INCLUDE_FORM_METRICS the counterpart n8n_form_submission_duration_seconds for form submissions. With N8N_METRICS_INCLUDE_WORKFLOW_INFO, a gauge n8n_workflow_info can additionally be enabled, which links workflow IDs with readable names, useful for Grafana panels without cryptic IDs.

Visualizing metrics with Grafana

Once the metrics are enabled, Prometheus takes over the collection via a scrape job that regularly queries the /metrics path of the n8n instance, by default n8n runs on port 5678. Grafana is then connected as a data source with the Prometheus server address. To get started, no dashboards need to be built from scratch: n8n publishes ready-made Grafana dashboards for the supported metrics in the GitHub project n8n-observability, including for webhook and form runtimes.

Important for context: the /metrics endpoint is only available for self-hosted instances, it is not available with n8n Cloud. Anyone wanting to work productively with self-hosting and full process control will find support with NordFlux's n8n consulting.

Frequently asked questions about monitoring in n8n

Is the /metrics endpoint available with n8n Cloud?

No, according to the n8n documentation, the Prometheus metrics endpoint is intended exclusively for self-hosted instances. It is not available for cloud instances.

Which log level is suitable for production operation?

The default value info generally provides sufficient context for ongoing operation. debug produces significantly more output and is mainly suited for investigating a specific incident in a targeted and time-limited way.

How do I monitor workers in a queue mode setup?

The health endpoint is disabled by default on worker instances in queue mode and must be enabled via QUEUE_HEALTH_CHECK_ACTIVE=true. In addition, N8N_METRICS_INCLUDE_QUEUE_METRICS=true provides metrics on active, completed, failed and waiting jobs in the queue.

Do I necessarily need Grafana to monitor n8n?

No. For simple uptime monitoring, the /healthz or /healthz/readiness endpoint is sufficient, which many monitoring tools can query directly via an HTTP check. Grafana only becomes relevant when detailed histories, queue or latency data from the /metrics endpoint need to be visualized graphically.