Workflows Missing in UI but Still Executing in the Background

Questions
1

I am running an n8n cluster setup (master/workers/webhook) using PostgreSQL, and my workflows have suddenly disappeared from the Web UI. I see the “Workflow Not Found” error when trying to open or access them.

Crucially: I can confirm that the workflows are still running successfully in the background (they are generating execution history). The core data exists in the database, but the UI/API layer cannot retrieve the list or access the workflow definitions.

This issue started immediately after an update attempt which caused temporary PostgreSQL instability.

What is the error message (if any)?

In the n8n UI, when trying to view a workflow by ID, the message is “Workflow Not Found.”

In the worker/master logs, there are no immediate errors, as the application seems to function, but it fails to load the metadata list.

Please share your workflow

Since I cannot access the workflows in the UI, I cannot copy and paste them into this thread.

I have confirmed via direct PostgreSQL query (SELECT id, name FROM workflow_entity;) that the workflow data is present and intact in the database tables.

Share the output returned by the last node

N/A, as the problem prevents workflow access and editing.

Information on your n8n setup

Setting Value Troubleshooting History
n8n version: n8nio/n8n:latest (or My original version (before upgrade) is unknown but stable.
Database: PostgreSQL Current Stable Version: postgres:17-alpine
EXECUTIONS_PROCESS setting: queue (Distributed Mode)
Running n8n via: Docker (Compose, distributed) PostgreSQL Connection Details: (Database Host: n8n-postgres-db, User: postgres)
Operating system: Debian 12

Troubleshooting Steps Already Taken:

  1. Fixed Database Instability: Reverted the PostgreSQL image tag from postgres:latest (which pulled v18, incompatible) back to postgres:17-alpine to match existing data. The DB is now Healthy.

  2. Repaired Indexes: Ran REINDEX TABLE workflow_entity; and REINDEX TABLE shared_workflow; directly on the database container to repair any corruption from the DB instability.

  3. Full Restart: Performed multiple docker restart and docker compose restart commands on all n8n services.

  4. Data Confirmation: Confirmed via direct psql query that the workflows and their data are physically present in the workflow_entity table.

The issue appears to be an incompatibility in the metadata reading/indexing layer of the current n8nio/n8n:latest application version, preventing the UI from retrieving the existing workflows from the PostgreSQL 17 data.

Does anyone have a solution to recover the workflows in the n8n UI

2

Hi @Laurin_Muller

What happens if you copy a workflow JSON from workflow_entitytable into the UI and save it?

If that works, then you could import all workflows this way for a fresh start.

Or is this not an option because you want to keep the full history and related data?

2 Likes
3

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.