We are faced n8n workflow getting disappeared issue on 15/7/2026 @3.30PM IST
Describe the problem/error/question
We are faced n8n workflow getting disappeared issue on 15/7/2026 @3.30PM IST
we need to find the root cause of the issue. Why n8n workflow getting disappeared. Post db restore all looks good
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:
- Database (default: SQLite):
- n8n EXECUTIONS_PROCESS setting (default: own, main):
- Running n8n via (Docker, npm, n8n cloud, desktop app):
- Operating system:
Hi @Raghavendra908 Welcome!
On self-hosted n8n this kind of mass disappearance is almost never n8n deleting workflows, it’s the database rolling back to an earlier state. Assuming the default SQLite, the usual trigger is a container restart, recreate, or host/VPS migration around that time where the SQLite WAL file (database.sqlite-wal) wasn’t checkpointed or wasn’t kept with the main DB, so everything written since the last checkpoint is gone. That fits your 3:30 PM IST timestamp and the DB restore bringing it all back.
To confirm the root cause, check the n8n container and host logs around 15/7 3:30 PM IST for a restart, an OOM kill, or SQLite errors, and verify that database.sqlite, database.sqlite-wal, and database.sqlite-shm all sit on the same persistent volume. The gap in the updatedAt column of the workflow_entity table will line up with the last good checkpoint.
For production, move off SQLite to Postgres and run real server-level backups (pg_dump on a cron), since SQLite is prone to exactly this under restarts and migrations.
Anshul’s diagnosis is spot on, and it’s worth underlining for anyone else who lands on this thread later: this failure mode (SQLite silently rolling back to an earlier checkpoint after a restart/OOM/host migration) is structural to running n8n on its default DB, not something you configured wrong. The WAL file and the main .sqlite file have to survive together on the exact same volume with a clean checkpoint, and a container restart/redeploy is exactly the moment that’s most likely to go sideways.
Moving to Postgres is the right fix. One gotcha worth knowing before you do it, since it trips people up almost as often as the DB migration itself: N8N_ENCRYPTION_KEY has to be pinned and never regenerated across deploys. If it changes (easy to do by accident if you’re not explicitly persisting it), every stored credential silently becomes unreadable - so you fix the data-loss problem and immediately hit a “why can’t n8n decrypt my credentials anymore” problem instead.
Full disclosure since I’m bringing up a specific way to do this: I maintain a one-click Railway template that wires this up already (n8n on Postgres 17 on its own volume, encryption key pinned via a generated secret so it never rotates underneath you, binary data written to Postgres instead of container-local disk) - kickback applies if you deploy through it: Deploy & Host n8n with Postgres | Railway . If you’re rolling your own docker-compose instead, the encryption-key-pinning point above is the one thing worth getting right regardless of where you host it.