Saltar a contenido

n8n devuelve 503 en / (legacy en lebron) — 2026-10-29

https://n8n.gorkarevilla.com y el puerto directo 5678 devuelven 503, aunque el contenedor n8n_main está Up y /healthz responde ok. Es el único monitor HTTP de Uptime Kuma en DOWN.

Estado

Campo Valor
Primera aparición 2026-10-29 (detectado por Uptime Kuma)
Estado Resuelto
Resuelto 2026-10-30
Severidad Media
Servicios afectados n8n (legacy), monitor n8n y grupo HTTPS de Uptime Kuma

Síntomas

  • curl -I https://n8n.gorkarevilla.com → 503 (respuesta JSON de n8n, server: cloudflare).
  • Directo en lebron: curl http://127.0.0.1:5678/ → 503; curl http://127.0.0.1:5678/healthz → {"status":"ok"}.
  • Contenedores n8n_main, n8n_worker_1, n8n_runner_1, n8n_redis y postgres están Up; NPM solo hace de proxy.
  • Logs de n8n_main con errores intermitentes:
  • getaddrinfo EAI_AGAIN postgres
  • timeout exceeded when trying to connect
  • Connection terminated due to connection timeout
  • job stalled more than maxStalledCount

Causa raíz

Sin confirmar. Las pistas apuntan a problemas de resolución/conexión a postgres desde el contenedor (DNS embebido de Docker o saturación de conexiones), que dejan la instancia en un estado en el que / responde 503 aunque el liveness /healthz siga OK. n8n está en modo cola con Redis.

Lo que se descartó

Hipótesis Resultado
Contenedor caído No: n8n_main lleva 5 semanas Up; /healthz OK
NPM mal configurado No: el fallo se reproduce en el puerto directo 5678
Redis caído No: n8n_redis está healthy
Postgres caído No: contenedor postgres healthy; habría que revisar su log y conexiones

Plan de acción

  1. Revisar logs de postgres (docker logs postgres) y el número de conexiones frente a max_connections.
  2. Comprobar DNS desde dentro de n8n_main (docker exec n8n_main getent hosts postgres / nslookup) y el /etc/resolv.conf del contenedor.
  3. Revisar la salud de la cola Bull/Redis y los workers (n8n_worker_1).
  4. Solución de fondo: migrar n8n a k3s con PostgreSQL en CloudNativePG (Fase 3 del roadmap).

Resolución

El 2026-10-30 se migró n8n a k3s (namespace n8n) con base de datos nueva (no había credenciales ni workflows reales que migrar). El legacy quedó parado y sus servicios se retiraron del stack ai de portainer-compose. La incidencia de conexión contra Postgres desaparece al dejar de usar el stack legacy.

Referencias