Self-hosted n8n instance returning persistent HTTP 502 errors and remaining offline, despite services running and no recent configuration changes

Questions
1

Hello everyone,

I’m experiencing a persistent HTTP 502 error on a self-hosted n8n instance, and the environment has been completely inaccessible for several hours.

image
image1919×991 18.3 KB

Context

  • n8n is self-hosted

  • The instance suddenly went offline

  • Error: HTTP 502 (Bad Gateway)

  • No recent configuration or infrastructure changes

  • This environment is business-critical and handles CRM and lead automation

What has already been checked

  • Server is up and has available CPU, RAM, and disk space

  • Docker container is running (docker ps)

  • n8n service restarted multiple times

  • Reverse proxy (Nginx/Traefik) configuration reviewed

  • No database space issues detected

  • Error persists after full restart

Observed behavior

  • UI is inaccessible

  • Reverse proxy returns 502

  • n8n logs do not clearly indicate a crash loop

  • Status page link (status.n8n.io) was temporarily unreachable from my side (DNS error)

Question

Has anyone experienced a similar situation where:

  • The container is running

  • Infrastructure looks healthy

  • But n8n still returns HTTP 502?

Any insights on less obvious root causes, logs to focus on, or recovery steps would be greatly appreciated.

Thank you in advance.

2

I’ve debugged this exact scenario multiple times with self-hosted n8n infrastructure. When the container shows as “running” but you’re getting 502 errors, it usually means the n8n process inside the container has crashed or isn’t listening on the expected port.

Immediate Diagnostic Steps

1. Check n8n Logs (Critical)

docker logs <container-name> --tail 100 --follow

Look for:

  • Uncaught exceptions or crashes
  • “Address already in use” errors
  • Database connection failures
  • Memory/OOM errors

2. Verify n8n Process is Actually Running

docker exec <container-name> ps aux | grep n8n

If you don’t see the node process, the container is up but n8n crashed.

3. Test Port Listening Inside Container

docker exec <container-name> netstat -tuln | grep 5678
# or
docker exec <container-name> curl http://localhost:5678/healthz

If port 5678 isn’t listening, n8n isn’t running.

Common Root Causes

Database Connection Lost

  • PostgreSQL/MySQL container restarted and n8n lost connection
  • Check: docker logs <db-container>
  • Fix: Restart n8n container (not just the n8n service)

Environment Variable Issues

  • Missing or changed N8N_PORT, N8N_HOST, WEBHOOK_URL
  • Check: docker inspect <container-name> and verify env vars

File Permission/Volume Mount Issues

  • n8n can’t write to .n8n directory
  • Check: docker exec <container-name> ls -la /home/node/.n8n
  • Fix: chown -R 1000:1000 /path/to/.n8n on host

Memory Exhaustion

  • Workflow with memory leak consumed all RAM
  • Check: docker stats
  • Fix: Increase memory limit or identify problematic workflow

Quick Recovery Steps

1. Full Container Restart (not just n8n service)

docker restart <container-name>
# Wait 30 seconds, then check logs
docker logs <container-name> --tail 50

2. If restart fails, recreate container

docker stop <container-name>
docker rm <container-name>
docker-compose up -d  # or your docker run command

3. Database connection reset

docker restart <db-container>
sleep 10
docker restart <n8n-container>

Business-Critical Recovery Tip

Since you mentioned this handles CRM/lead automation, I’d recommend:

  1. Set up health check endpoint monitoring (UptimeRobot, BetterStack)
  2. Configure container restart policy: --restart unless-stopped
  3. Add resource limits to prevent memory exhaustion
  4. Enable database connection pooling with retry logic

I’ve set up production n8n environments for clients with similar use cases - the most common culprit is database connection loss after an automatic container update or host reboot.

Run those diagnostic commands and share the output if you’re still stuck. Happy to help get you back online!