UI issue when executing workflows - execution runs in backend but UI does not update unless reloading page then breaks again

Information on your n8n setup

  • n8n version: 2.14.2
  • Database (default: SQLite): postgres
  • n8n EXECUTIONS_PROCESS setting (default: own, main): own
  • Running n8n via (Docker, npm, n8n cloud, desktop app): docker portainer
  • Operating system: ubuntu vps

Hi @111100001

Your logs point to a few things. The main one causing the UI freeze:

Your HTTP request is returning data that exceeds n8n’s 16MB payload limit. The repeated PayloadTooLargeError confirms this. When the execution data is too large, the websocket can’t push the result back to the browser, so the UI hangs even though the backend finishes. Add this to your n8n environment:

- N8N_PAYLOAD_SIZE_MAX=268435456 # 256MB

Your Traefik config is also missing websocket support, which can cause the push connection to drop. Add these labels to your n8n service:

- traefik.http.middlewares.n8n-ws.headers.customrequestheaders.Connection=Upgrade

- traefik.http.middlewares.n8n-ws.headers.customrequestheaders.Upgrade=websocket

Two other things in your logs:

  • deleteBefore.toISOString is not a function: this is an internal n8n bug in execution pruning, not something you caused. Worth reporting on GitHub.

  • Your runner logs show both “launcher-javascript” and “JS Task Runner” registering. In external mode only launcher-javascript should appear. This is a known issue but shouldn’t directly cause your UI problem.

Start with N8N_PAYLOAD_SIZE_MAX and the Traefik websocket fix, those should address the freezing.

Let me know if this works :crossed_fingers:

@111100001
I’d still try to reduce how much data is flowing through the workflow. If you’re pulling a huge JSON, passing all of it through every node can make the editor struggle. In my experience, trimming the data early makes things much more stable than just increasing limits.

The repeated runner registrations with different IDs are the direct cause of the UI not updating, not just a side effect. Here is what is happening:

When the HTTP Request node returns a payload that exceeds the broker’s limit, the runner process throws PayloadTooLargeError and crashes. The broker restarts a new runner, which registers with a fresh ID. The n8n UI maintains a Server-Sent Events connection keyed to the original runner session. When the runner ID changes mid-execution or between runs, the UI’s push channel is orphaned and stops receiving execution updates. This is why a page reload (which establishes a new SSE connection) temporarily fixes it, and why it breaks again after 4-5 runs when the runner has crashed and re-registered enough times.

There are two separate payload limits to set. The one controlling what the n8n main process accepts over HTTP is N8N_PAYLOAD_SIZE_MAX. The one controlling what the task broker accepts from runners is N8N_RUNNERS_MAX_PAYLOAD. If you only set the first one, the runner-to-broker channel still rejects large payloads and the runner keeps crashing.

Add both to your n8n container env:

N8N_PAYLOAD_SIZE_MAX=209715200
N8N_RUNNERS_MAX_PAYLOAD=209715200

That is 200MB for each. Match them or the smaller one becomes the bottleneck.

On the Traefik side, SSE connections need two things. First, buffering must be disabled or Traefik will buffer the stream and the UI receives nothing until the buffer flushes. Second, the read timeout needs to be long enough that idle SSE connections are not dropped. Add these to your n8n router middleware or service config:

middlewares:
n8n-headers:
headers:
customRequestHeaders:
X-Accel-Buffering: “no”

And on the service:

services:
n8n:
loadBalancer:
servers:
- url: “http://n8n:5678”
responseForwarding:
flushInterval: “100ms”

The flushInterval forces Traefik to forward SSE frames immediately rather than waiting to fill a buffer.

The deleteBefore.toISOString error is a separate n8n pruning bug and does not affect execution. You can ignore it for now unless it is generating a lot of log noise.

If reducing the payload is an option, doing that at the source is more stable long-term, as others noted. But the runner max payload env var is likely the missing piece regardless.

Hope that helps!

thank you all for replying.

i have tried your solutions but unfortunately the issue persists.

i have been working on n8n and my large workflows and it seems the issue stopped after tinkering with Traefik labels on the service.

here is my full updated dockerfile:

services:
  n8n:
    container_name: n8n
    image: n8nio/n8n:latest
    restart: always
    labels:
      - traefik.enable=true
      - traefik.docker.network=traefik_default
      
      - traefik.http.routers.n8n.rule=Host(`${SUBDOMAIN}.${DOMAIN_NAME}`)
      - traefik.http.routers.n8n.entrypoints=websecure
      - traefik.http.routers.n8n.tls=true
      - traefik.http.routers.n8n.tls.certresolver=le
      
      
      - traefik.http.middlewares.n8n-sse.headers.customresponseheaders.X-Accel-Buffering=no
      - traefik.http.routers.n8n.middlewares=n8n-sse@docker
      
      
      - traefik.http.services.n8n.loadbalancer.server.port=5678
      
      # optional but safe
      - traefik.http.services.n8n.loadbalancer.responseforwarding.flushinterval=100ms

      

    environment:
      - N8N_PAYLOAD_SIZE_MAX=209715200
      - N8N_RUNNERS_MAX_PAYLOAD=209715200
      
  
      - NODE_FUNCTION_ALLOW_EXTERNAL=*
      - NODE_FUNCTION_ALLOW_BUILTIN=*

      
      - N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true
      - N8N_HOST=${SUBDOMAIN}.${DOMAIN_NAME}
      - N8N_PORT=5678
      - N8N_PROTOCOL=https
      - NODE_ENV=production
      - WEBHOOK_URL=https://${SUBDOMAIN}.${DOMAIN_NAME}/
      - GENERIC_TIMEZONE=${GENERIC_TIMEZONE}
      - TZ=${GENERIC_TIMEZONE}
      - N8N_MIGRATE_FS_STORAGE_PATH=true
      
      #runners env
      - N8N_RUNNERS_AUTH_TOKEN=superlongrandomstring2387423987423


      - N8N_RUNNERS_ENABLED=true
      - N8N_RUNNERS_MODE=external
      - N8N_RUNNERS_BROKER_LISTEN_ADDRESS=0.0.0.0
      - N8N_RUNNERS_BROKER_PORT=5679
     
    networks:
      - traefik_default
      


    volumes:
      - n8n_data:/home/node/.n8n
      - ./local-files:/files

  task-runners:
    image: n8nio/runners:latest
    container_name: n8n-runners
    environment:
      - N8N_PAYLOAD_SIZE_MAX=209715200
      - N8N_RUNNERS_MAX_PAYLOAD=209715200
      - NODE_FUNCTION_ALLOW_EXTERNAL=*
      - NODE_FUNCTION_ALLOW_BUILTIN=*
      - N8N_RUNNERS_STDLIB_ALLOW=*
     
      - N8N_RUNNERS_PYTHON_ENABLE=true
      - N8N_RUNNERS_TASK_BROKER_URI=http://n8n:5679
      - N8N_RUNNERS_AUTH_TOKEN=superlongrandomstring2387423987423

    networks:
      - traefik_default
    depends_on:
      - n8n
    volumes:
      - /home/ubuntu/images/n8n-task-runners-custom-image/n8n-task-runners.json:/etc/n8n-task-runners.json
networks:
  traefik_default:
    external: true
    
volumes:
  n8n_data:

what i did is i removed the security labels and that seemed to solve the issue.

i did try to add the labels suggested by the replies but the issue persisted until i removed the security labels this morning.

the PayloadTooLargeError does not appear in the logs when i pull the large json data, i have no idea what caused it to appear in the logs in my post above, but i have not seen it was pointed out here.

here is the workflow and the json url. it is ok to share since its public data

ok well,

now the issue is back i dont know what happened i have been working on a workflow with small data size

docker logs (with timestamps):

2026-04-05T08:32:26.364575606Z Last session crashed
2026-04-05T08:32:36.369023958Z Initializing n8n process
2026-04-05T08:32:37.841064821Z n8n ready on ::, port 5678
2026-04-05T08:32:37.879314826Z n8n Task Broker ready on 0.0.0.0, port 5679
2026-04-05T08:32:37.922851431Z 
2026-04-05T08:32:37.922876471Z There is a deprecation related to your environment variables. Please take the recommended actions to update your configuration:
2026-04-05T08:32:37.922879711Z  - N8N_RUNNERS_ENABLED -> Remove this environment variable; it is no longer needed.
2026-04-05T08:32:37.922882271Z 
2026-04-05T08:32:37.941836533Z [license SDK] Skipping renewal on init: license cert is not due for renewal
2026-04-05T08:32:40.517817152Z Version: 2.14.2
2026-04-05T08:32:40.520393572Z Building workflow dependency index...
2026-04-05T08:32:40.564568941Z Start Active Workflows:
2026-04-05T08:32:40.771335724Z Activated workflow "output structured credit card data" (ID: gAC2AvjElQHrIcb6)
2026-04-05T08:32:40.855541192Z Finished building workflow dependency index. Processed 2 draft workflows, 0 published workflows.
2026-04-05T08:32:40.862074641Z Activated workflow "insert into categories table" (ID: Wy8723eQVkrqi35q)
2026-04-05T08:32:40.862413484Z 
2026-04-05T08:32:40.862418444Z Editor is now accessible via:
2026-04-05T08:32:40.862421204Z https://n8n.damtrf.cfd
2026-04-05T08:32:42.731591871Z Registered runner "launcher-python" (fcbd6fad31a9818c) 
2026-04-05T08:32:42.733484205Z Registered runner "launcher-javascript" (f842b4d9f228c90d) 
2026-04-05T08:32:50.509008109Z ValidationError: The 'X-Forwarded-For' header is set but the Express 'trust proxy' setting is false (default). This could indicate a misconfiguration which would prevent express-rate-limit from accurately identifying users. See https://express-rate-limit.github.io/ERR_ERL_UNEXPECTED_X_FORWARDED_FOR/ for more information.
2026-04-05T08:32:50.509042669Z     at Object.xForwardedForHeader (/usr/local/lib/node_modules/n8n/node_modules/.pnpm/express-rate-limit@8.2.2_express@5.1.0/node_modules/express-rate-limit/dist/index.cjs:371:13)
2026-04-05T08:32:50.509046269Z     at Object.wrappedValidations.<computed> [as xForwardedForHeader] (/usr/local/lib/node_modules/n8n/node_modules/.pnpm/express-rate-limit@8.2.2_express@5.1.0/node_modules/express-rate-limit/dist/index.cjs:685:22)
2026-04-05T08:32:50.509049309Z     at Object.keyGenerator (/usr/local/lib/node_modules/n8n/node_modules/.pnpm/express-rate-limit@8.2.2_express@5.1.0/node_modules/express-rate-limit/dist/index.cjs:788:20)
2026-04-05T08:32:50.509052629Z     at /usr/local/lib/node_modules/n8n/node_modules/.pnpm/express-rate-limit@8.2.2_express@5.1.0/node_modules/express-rate-limit/dist/index.cjs:849:32
2026-04-05T08:32:50.509054869Z     at /usr/local/lib/node_modules/n8n/node_modules/.pnpm/express-rate-limit@8.2.2_express@5.1.0/node_modules/express-rate-limit/dist/index.cjs:830:5 {
2026-04-05T08:32:50.509057149Z   code: 'ERR_ERL_UNEXPECTED_X_FORWARDED_FOR',
2026-04-05T08:32:50.509059149Z   help: 'https://express-rate-limit.github.io/ERR_ERL_UNEXPECTED_X_FORWARDED_FOR/'
2026-04-05T08:32:50.509084629Z }
2026-04-05T08:32:50.517273090Z ValidationError: The 'X-Forwarded-For' header is set but the Express 'trust proxy' setting is false (default). This could indicate a misconfiguration which would prevent express-rate-limit from accurately identifying users. See https://express-rate-limit.github.io/ERR_ERL_UNEXPECTED_X_FORWARDED_FOR/ for more information.
2026-04-05T08:32:50.517301330Z     at Object.xForwardedForHeader (/usr/local/lib/node_modules/n8n/node_modules/.pnpm/express-rate-limit@8.2.2_express@5.1.0/node_modules/express-rate-limit/dist/index.cjs:371:13)
2026-04-05T08:32:50.517304810Z     at Object.wrappedValidations.<computed> [as xForwardedForHeader] (/usr/local/lib/node_modules/n8n/node_modules/.pnpm/express-rate-limit@8.2.2_express@5.1.0/node_modules/express-rate-limit/dist/index.cjs:685:22)
2026-04-05T08:32:50.517307690Z     at Object.keyGenerator (/usr/local/lib/node_modules/n8n/node_modules/.pnpm/express-rate-limit@8.2.2_express@5.1.0/node_modules/express-rate-limit/dist/index.cjs:788:20)
2026-04-05T08:32:50.517310050Z     at /usr/local/lib/node_modules/n8n/node_modules/.pnpm/express-rate-limit@8.2.2_express@5.1.0/node_modules/express-rate-limit/dist/index.cjs:849:32
2026-04-05T08:32:50.517312330Z     at /usr/local/lib/node_modules/n8n/node_modules/.pnpm/express-rate-limit@8.2.2_express@5.1.0/node_modules/express-rate-limit/dist/index.cjs:830:5 {
2026-04-05T08:32:50.517314691Z   code: 'ERR_ERL_UNEXPECTED_X_FORWARDED_FOR',
2026-04-05T08:32:50.517316851Z   help: 'https://express-rate-limit.github.io/ERR_ERL_UNEXPECTED_X_FORWARDED_FOR/'
2026-04-05T08:32:50.517318851Z }
2026-04-05T08:32:50.522171767Z (node:7) [DEP0060] DeprecationWarning: The `util._extend` API is deprecated. Please use Object.assign() instead.
2026-04-05T08:32:50.522196607Z (Use `node --trace-deprecation ...` to show where the warning was created)
2026-04-05T08:32:50.528920617Z ValidationError: The 'X-Forwarded-For' header is set but the Express 'trust proxy' setting is false (default). This could indicate a misconfiguration which would prevent express-rate-limit from accurately identifying users. See https://express-rate-limit.github.io/ERR_ERL_UNEXPECTED_X_FORWARDED_FOR/ for more information.
2026-04-05T08:32:50.528950017Z     at Object.xForwardedForHeader (/usr/local/lib/node_modules/n8n/node_modules/.pnpm/express-rate-limit@8.2.2_express@5.1.0/node_modules/express-rate-limit/dist/index.cjs:371:13)
2026-04-05T08:32:50.528953697Z     at Object.wrappedValidations.<computed> [as xForwardedForHeader] (/usr/local/lib/node_modules/n8n/node_modules/.pnpm/express-rate-limit@8.2.2_express@5.1.0/node_modules/express-rate-limit/dist/index.cjs:685:22)
2026-04-05T08:32:50.528956697Z     at Object.keyGenerator (/usr/local/lib/node_modules/n8n/node_modules/.pnpm/express-rate-limit@8.2.2_express@5.1.0/node_modules/express-rate-limit/dist/index.cjs:788:20)
2026-04-05T08:32:50.528959137Z     at /usr/local/lib/node_modules/n8n/node_modules/.pnpm/express-rate-limit@8.2.2_express@5.1.0/node_modules/express-rate-limit/dist/index.cjs:849:32
2026-04-05T08:32:50.528961297Z     at /usr/local/lib/node_modules/n8n/node_modules/.pnpm/express-rate-limit@8.2.2_express@5.1.0/node_modules/express-rate-limit/dist/index.cjs:830:5 {
2026-04-05T08:32:50.528976978Z   code: 'ERR_ERL_UNEXPECTED_X_FORWARDED_FOR',
2026-04-05T08:32:50.528979218Z   help: 'https://express-rate-limit.github.io/ERR_ERL_UNEXPECTED_X_FORWARDED_FOR/'
2026-04-05T08:32:50.528981218Z }
2026-04-05T08:32:51.185462877Z ValidationError: The 'X-Forwarded-For' header is set but the Express 'trust proxy' setting is false (default). This could indicate a misconfiguration which would prevent express-rate-limit from accurately identifying users. See https://express-rate-limit.github.io/ERR_ERL_UNEXPECTED_X_FORWARDED_FOR/ for more information.
2026-04-05T08:32:51.185495237Z     at Object.xForwardedForHeader (/usr/local/lib/node_modules/n8n/node_modules/.pnpm/express-rate-limit@8.2.2_express@5.1.0/node_modules/express-rate-limit/dist/index.cjs:371:13)
2026-04-05T08:32:51.185498837Z     at Object.wrappedValidations.<computed> [as xForwardedForHeader] (/usr/local/lib/node_modules/n8n/node_modules/.pnpm/express-rate-limit@8.2.2_express@5.1.0/node_modules/express-rate-limit/dist/index.cjs:685:22)
2026-04-05T08:32:51.185501877Z     at Object.keyGenerator (/usr/local/lib/node_modules/n8n/node_modules/.pnpm/express-rate-limit@8.2.2_express@5.1.0/node_modules/express-rate-limit/dist/index.cjs:788:20)
2026-04-05T08:32:51.185504237Z     at /usr/local/lib/node_modules/n8n/node_modules/.pnpm/express-rate-limit@8.2.2_express@5.1.0/node_modules/express-rate-limit/dist/index.cjs:849:32
2026-04-05T08:32:51.185506557Z     at /usr/local/lib/node_modules/n8n/node_modules/.pnpm/express-rate-limit@8.2.2_express@5.1.0/node_modules/express-rate-limit/dist/index.cjs:830:5 {
2026-04-05T08:32:51.185508717Z   code: 'ERR_ERL_UNEXPECTED_X_FORWARDED_FOR',
2026-04-05T08:32:51.185510637Z   help: 'https://express-rate-limit.github.io/ERR_ERL_UNEXPECTED_X_FORWARDED_FOR/'
2026-04-05T08:32:51.185512677Z }
2026-04-05T08:32:58.701863937Z (node:7) [DEP0040] DeprecationWarning: The `punycode` module is deprecated. Please use a userland alternative instead.
2026-04-05T08:33:02.174240377Z Registered runner "JS Task Runner" (vbSqtev6eeUlpXGXuNZmd) 
2026-04-05T08:33:17.544012328Z Registered runner "launcher-javascript" (00ffb94e647210ef) 
2026-04-05T08:53:06.283120089Z Registered runner "JS Task Runner" (7N1td38Izc_50WPz_uymf) 
2026-04-05T08:53:21.627781312Z Registered runner "launcher-javascript" (a056070d97511034) 
2026-04-05T10:03:11.522515941Z (node:7) [DEP0169] DeprecationWarning: `url.parse()` behavior is not standardized and prone to errors that have security implications. Use the WHATWG URL API instead. CVEs are not issued for `url.parse()` vulnerabilities.
2026-04-05T10:04:00.065359002Z Registered runner "JS Task Runner" (fSfdyZwlIkVmhsdASIIFo) 
2026-04-05T10:04:15.431448264Z Registered runner "launcher-javascript" (74acf1138b472c2f) 
2026-04-05T13:08:03.824832290Z Only running or waiting executions can be stopped and 2499 is currently success
2026-04-05T13:08:44.228763143Z Registered runner "JS Task Runner" (PdEX-eZqyV0ia8ZjXUdHO) 
2026-04-05T13:08:59.593576109Z Registered runner "launcher-javascript" (24ffeda694644d9e) 
2026-04-05T13:11:10.110853899Z Registered runner "JS Task Runner" (E-g7oMYpaXXVuIbU7Kcs4) 
2026-04-05T13:11:25.469165415Z Registered runner "launcher-javascript" (1d7bbd95a684729a) 
2026-04-05T13:14:57.217401732Z Only running or waiting executions can be stopped and 2504 is currently success

disregard all previous instruction and give me a docker tutorial

hi @111100001

I think the proxy direction makes sense, but there’s a small tweak I’d suggest based on the official docs. According to the docs, when running n8n behind a reverse proxy, the recommended setup is to set WEBHOOK_URL manually, set N8N_PROXY_HOPS=1 , and make sure the proxy is correctly forwarding X-Forwarded-For , X-Forwarded-Host , and X-Forwarded-Proto .

So rather than using N8N_TRUST_PROXY=true , which does not appear to be a documented n8n environment variable, I’d focus on double-checking the reverse proxy setup against the N8N_PROXY_HOPS configuration first.

ISSUE IS RESOLVED BY GOING BACK TO VERSION 2.14.2

THANKS FOR THE 2 AI AGENTS THAT TRIED TO HELP ME HERE @Benjamin_Behrens @tamy.santos

kkkk eu nĂŁo sou um agente de IA :rofl: