Execution List will not show flow - shows an orange spinner on it

Help me Build my Workflow
1

Describe the problem/error/question

When I try to open workflow execution details, the executions list shows them as “succeeded,” but the details panel just spins forever. I don’t see the JSON output of the run.

If I copy the execution back into the editor, I can see what it did — so the execution data is stored in Postgres, but the execution viewer in the UI fails to load it.

image

When

What is the error message (if any)?

Please share your workflow

(Select the nodes on your canvas and use the keyboard shortcuts CMD+C/CTRL+C and CMD+V/CTRL+V to copy and paste the workflow.)

Share the output returned by the last node

Information on your n8n setup

  • n8n version: 1.108.2

  • Database: Postgres 17 (via Docker, not SQLite)

  • n8n EXECUTIONS_PROCESS: (default → main)

  • Running n8n via: Docker (Dokploy stack with Traefik reverse proxy)

  • Operating system: Ubuntu 24.04 (inside VM on Proxmox)

Additional info:

  • I have N8N_ENCRYPTION_KEY set and data persisted in Docker volumes.

  • Proxy headers come from Traefik.

  • Logs also show [DEP0060] DeprecationWarning: The util._extend API is deprecated, but I think that’s unrelated.

  • Debug logging shows constant Querying database for waiting executions from wait-tracker.js.

Execution List will not show flow - has an orange spinner on it
2

Root Causes Found:

1. Conflicting X-Frame-Options Headers

Both the reverse proxy and n8n were setting X-Frame-Options headers with different values:

  • Proxy was setting: X-Frame-Options: DENY

  • n8n was setting: X-Frame-Options: SAMEORIGIN

This caused the browser to refuse loading execution data with error:

Refused to display '[n8n-url]' in a frame because it set multiple 'X-Frame-Options' headers with conflicting values ('DENY, SAMEORIGIN')

2. WebSocket Support Missing

n8n uses WebSockets for real-time updates on the executions page. The reverse proxy wasn’t properly configured for WebSocket connections, causing the UI to hang waiting for data that never arrived.

3. HTTP/2 Incompatibility

WebSocket protocol upgrades require HTTP/1.1. The proxy was using HTTP/2 by default, which doesn’t support the protocol switching needed for WebSocket connections.

Solution:

Updated Caddy reverse proxy configuration to:

  1. Remove header conflicts:

caddyfile

header {
    -X-Frame-Options  # Remove existing header first
    X-Frame-Options SAMEORIGIN  # Set the value n8n expects
}
  1. Force HTTP/1.1 for WebSocket support:

caddyfile

reverse_proxy [backend] {
    transport http {
        versions 1.1
    }
}
  1. Add proper forwarding headers:

caddyfile

header_up X-Real-IP {remote}
header_up X-Forwarded-For {remote}
header_up X-Forwarded-Proto {scheme}

After applying these changes and reloading the proxy, the executions page loads correctly.

Key Lesson: When running n8n behind a reverse proxy, ensure:

  • No conflicting security headers between proxy and n8n

  • WebSocket support is properly configured

  • HTTP/1.1 is used for backend connections to support WebSocket upgrades