N8N SERVER 502 Error Gateway

[Micka_Rakotomalala]

Hello everyone,

I have a problem on N8N, when my process runs with more than 12,000 rows of data already using split in batch, also the node call workflow id, my server bug, there is the error if the figure, also I can no longer access my server until two hours later.

URL : N8N SERVER 502 Bad Gateway error

The node [HR QC 2.0 - SOURCE 2] WRITE IN FILE takes over 50 minutes to complete

Can you help me?

Thanks.

.env
QUEUE_BULL_REDIS_HOST=redis

COMPOSE_HTTP_TIMEOUT=3600

Set the logging level to ‘debug’
N8N_LOG_LEVEL=debug

Set log output to both console
N8N_LOG_OUTPUT=console

Set a 50 MB maximum size for each log file
N8N_LOG_FILE_MAXSIZE=500

EXECUTIONS_DATA_SAVE_ON_ERROR=all
EXECUTIONS_DATA_SAVE_ON_PROGRESS=false
EXECUTIONS_DATA_SAVE_ON_SUCCESS=none
EXECUTIONS_DATA_SAVE_MANUAL_EXECUTIONS=false

EXECUTIONS_DATA_PRUNE=true
EXECUTIONS_DATA_MAX_AGE=168
EXECUTIONS_DATA_PRUNE_MAX_COUNT=50000

docker-compose.yml
version: ‘3.1’

services:

postgres:
image: postgres:11
container_name: postgres
restart: always
ports:

• 5435:5432
  env_file:
• .env
  volumes:
• /opt/n8n-XXX/data/database/postgresql:/var/lib/postgresql/data
  networks:
• servernet

redis:
image: redis:6-alpine
container_name: redis
restart: always
volumes:

• redis_storage:/data
  healthcheck:
  test: [“CMD”, “redis-cli”, “ping”]
  interval: 5s
  timeout: 20s
  retries: 10

mongo:
image: mongo:4.4
env_file:

• .env
  ports:
• “27018:27017”
  networks:
• servernet
  volumes:
• my-mongo-volume:/data

n8n:
image: n8nio/n8n:1.5.1
labels:

• io.portainer.accesscontrol.teams=developpement
  restart: always
  env_file:
• .env
  ports:
• 5678:5678
  extra_hosts:
• “DNS.XXX.XXX:IP.XX.XXX.XXX”
  links:
• postgres
• redis
• mongo
  labels:
• traefik.enable=true
• traefik.http.routers.n8n.rule=Host(${SUBDOMAIN}.${DOMAIN_NAME})
• traefik.http.routers.n8n.tls=true
• traefik.http.routers.n8n.entrypoints=web,websecure
• traefik.http.routers.n8n.tls.certresolver=mytlschallenge
• traefik.http.middlewares.n8n.headers.SSLRedirect=true
• traefik.http.middlewares.n8n.headers.STSSeconds=315360000
• traefik.http.middlewares.n8n.headers.browserXSSFilter=true
• traefik.http.middlewares.n8n.headers.contentTypeNosniff=true
• traefik.http.middlewares.n8n.headers.forceSTSHeader=true
• traefik.http.middlewares.n8n.headers.SSLHost=${DOMAIN_NAME}
• traefik.http.middlewares.n8n.headers.STSIncludeSubdomains=true
• traefik.http.middlewares.n8n.headers.STSPreload=true
• traefik.http.routers.n8n.middlewares=n8n@docker
  volumes:
• /opt/n8n_XX:/home/node/
• /opt/sftp-n8n/data/uploads:/home/data
  command: “start”
  depends_on:
• postgres
• redis
• mongo
  networks:
• servernet

networks:
servernet:
driver: bridge

volumes:
n8n_storage:
redis_storage:
my-mongo-volume:
external: false

Information on your n8n setup
n8n 1.8.2
Database using:Postgresql
**third-party database: Baserow
Running n8n with the execution process [own(default), main]:own
Running n8n via [Docker, npm, n8n.cloud, desktop app]:Docker

[Micka_Rakotomalala]

Finding in logs and block to access workflow, I need to refresh page

[EmeraldHerald]

Hi @Micka_Rakotomalala It sounds like this may be a memory issue, in which you’re simply processing too much data You can read about how to avoid memory errors here: Memory-related errors | n8n Docs This doc also includes some tips on how to avoid such errors

Your workflow, in this case, may need to be split up into multiple sub-workflows that can process smaller chunks of data. Can you try that out and see if that helps resolve the issue for you?

Can you also check your server logs for any errors during the execution of your workflow?

[Micka_Rakotomalala]

Hi @EmeraldHerald

Sorry for my late reply, I was on vacation. In fact, I applied the resolution with NODE_OPTIONS=“–max-old-space-size=22528” (including 32GB of RAM allocated for n8n and baserow in the same server) and also my data are already spliter by batch, I process my data little by little, I even used pin data. But all this still doesn’t solve my problems.
Maybe my Virtual Machine is the problem? In fact, I’ve limited the size of logs written to docker containers, to limit disk resource consumption, and I’ve also limited n8n logs.

I really don’t understand why I’m launching my processes with data on 6782 lines, the server has crashed, hence the 502 error that appears.

[EmeraldHerald]

Hi @Micka_Rakotomalala

Could you share some server logs from the time of the crash? Any errors that we can see would be really helpful in trying to diagnose this

[Micka_Rakotomalala]

In fact, I’ve set my timeout on the process to 2 hours, so it’s running for a very long time, after this 2-hour expiry I’ll have access to my platform again.

I don’t yet have access to my server logs, but I’ll let you know when I have it with the test of course.

[Micka_Rakotomalala]

Hi @EmeraldHerald

I see the logs and there were no errors, the container works and starts correctly. But the services in n8n bugs that makes the node crash in the image. So is it possible to start n8n with pm2 via docker to resolve this service crash?
At the moment, we’re trying to force a restart to get n8n working again.

[MutedJam]

So is it possible to start n8n with pm2 via docker to resolve this service crash?

Not quite sure I understand this requirement I am afraid. You can manage docker containers through pm2, but I’d strongly suggest you won’t since docker already has it’s own logic to restart containers if desired.

It seems you have already configured restart: always in your docker compose file. Seeing your logs do not contain any hints of a crash, I wonder if your workflow execution simply puts a very high load on n8n (and thus making it look like it has crashed because it’s not responding as expected, ultimately result in your reverse proxy reporting a 5xx status).

I see you’re setting up redis and configure queue mode in principle but can’t see any workers in your config. Do you have any workers set up? And are you running into this problem for production executions or for manual executions?

Manual executions would take place on the main instance, so if that’s when you’re running into the problem perhaps you want to test whether you’re seeing the same problem with a production execution (taking place on a worker instance, which should help keep your main instance responsive)?

[Micka_Rakotomalala]

It seems that when entering the n8n image container via docker exec, the process gets stuck on a node that takes a long time to execute. The container doesn’t detect any errors or crashes, but the node application, which starts n8n inside, is blocking a process that runs for a very long time. This results in slow access to the n8n platform. I thought about using “pm2 start” instead of “n8n start” to address this issue. However, the Docker container is functioning correctly without crashing.

Indeed, this high load, with over 50,000 lines, is it too much for a node?
It also causes temporary unavailability of the n8n platform, requiring a forced container restart.

Could you show how to manage Redis in n8n? I have created the service, but I am unsure if it is functioning as intended.

I encountered this issue during manual execution, but I haven’t deployed my process in production yet. I believe I will need to optimize it further.

[MutedJam]

@Micka_Rakotomalala

Indeed, this high load, with over 50,000 lines, is it too much for a node?

It depends on the exact data structure. But in general n8n does not have built-in logic to break down larger amounts of data during the workflow execution, so you’d need to handle this in your workflow. An example approach would be this one, where the parent workflow only processes very little data (essentially managing pagination) and the sub-workflow does the heavy lifting for smaller amounts of data.

Could you show how to manage Redis in n8n? I have created the service, but I am unsure if it is functioning as intended.

I believe Redis is not the problem here. It’s only needed to hand over production executions from the main n8n instance to the worker once you deploy one and fully switch to queue mode. You would configure the connection using the QUEUE_BULL_REDIS_HOST and QUEUE_BULL_REDIS_PORT environment variables in your n8n configuration as documented here.

But perhaps you want to consider a single instance setup for now to avoid the additional complexity coming with queue mode?