Hello everyone,
I would like to report an unexpected issue we encountered with our n8n instance.
From one day to the next, all workflows that were created before 2025 and were active were simply removed from our account. These workflows were running normally and were critical to our operations. There was no intentional action on our side (such as manual deletion, restore, or migration) that could explain this behavior.
For context, we are running n8n in a self-hosted environment.
Could this issue be related in any way to the release or changes introduced in version 2.0.2? We would appreciate any guidance, known issues, or similar reports from the community.
Thank you in advance for your support.
This is the message returned when one of our integrations tried to execute a workflow that was deleted: {“code”:404,“message”:“The requested webhook "POST 7ae86e2c-4819-4f24-892c-74bb8330fc70" is not registered.”,“hint”:“The workflow must be active for a production URL to run successfully. You can activate the workflow using the toggle in the top-right of the editor. Note that unlike test URL calls, production URL calls aren’t shown on the canvas (only in the executions list)”}
Yes, we have already checked the database. The workflows did exist in the workflow_entity table, and until yesterday, they were also visible in the n8n UI. I’m the admin of our n8n instance, so I have visibility over all active and inactive workflows.
At this point, the workflows are no longer present in the UI, and they are also missing from the database, which leads us to believe this is not a webhook registration issue but an actual deletion (or data loss) scenario.
Or maybe Docker images … is too broad to find the issue…and the “fault” here…
Do you have env variables loggs enabled for main instance at n8n level… eg:
N8N_LOG_LEVEL=debug # or info/warn/error
N8N_LOG_OUTPUT=console # or file, or console,file
N8N_LOG_FILE_LOCATION=/path/to/logs/n8n.log
N8N_LOG_FILE_SIZE_MAX=16 # MB
N8N_LOG_FILE_COUNT_MAX=100
Or db n8n level:
DB_LOGGING_ENABLED=true
DB_LOGGING_OPTIONS=error # or query, warn, all, etc.
DB_LOGGING_MAX_EXECUTION_TIME=1000
Then you need to check your external database (Postgres or MySQL), the database engine itself keeps logs independently of n8n.
Postgres/MySQLLogsghs:
Check the database’sss own systelogsggs for any “Drop Table,” “Truncte,” or “Delte” commands that occurred around the time of the inccident.
Without some logs, is near to impossible to find out why, besides the a bit older version ofn8n…
This is a image of the last logs executed (the ones from 16th December is me consulting the database). As the image shows, we didn’t have any action or command being executed in the database when the workflows were excluded from our account.
However, we found a very relevant log in our n8n CloudWatch log group on the same day the workflows disappeared.
n8n logged a slow query executing a batch DELETE FROM workflow_entity WHERE id IN (...).
This indicates the deletion was triggered by the application itself, not a webhook registration issue or database reset.
We did not intentionally delete these workflows via UI or API. Given this, could there be any known issue or regression in v2.0.2 that could trigger workflow deletions during migrations or background processes?
The only change I recall making around that time was attempting to remove a user who had been invited to our n8n instance but never accepted the invite. I’m not sure if this is related, but I’m wondering whether a bug in this flow could have resulted in workflows being deleted instead of the user.
If a user is deleted from the system, and that user was the Owner of those workflows, the database is configured to automatically delete all associated workflows(Cascading delete effect) ??
If an invite was never accepted, a record is created in the user table?
If workflows were created by or assigned to that internal ID, deleting that user via the UI/API triggers a DELETE command that propagates to the workflows??
Do you use RDS , or you manage yourself the PostgreSQL?
But to “recover” , the only way is a backup (daily, weekly… ).
If a user is deleted from the system, and that user was the Owner of those workflows, the database is configured to automatically delete all associated workflows(Cascading delete effect) ??
I know that when you delete a user you have two options:
to change the ownership of the workflows from that user to another one;
to delete the workflows altogether;
When the user doesn’t accept the invite, there aren’t any workflows associated with them, so these options don’t apply in this case.
If an invite was never accepted, a record is created in the user table?
Wouldn’t know the answer for that.
If workflows were created by or assigned to that internal ID, deleting that user via the UI/API triggers a DELETE command that propagates to the workflows??
It’s not possible to associate a workflow with a user that is not registered in the account (that never accepted an invite, for instance).
Do you use RDS , or you manage yourself the PostgreSQL?
We use PostgreSQL.
But to “recover” , the only way is a backup (daily, weekly… ).
Yeah. Luckily, we have a daily backup that will enable us to recover the deleted workflows. Nevertheless, we still need to understand what happened and why the workflows were deleted, so we don’t go through that again.
Since you didn’t delete them manually, a system process did it… The migrations table is your audit log for structural changes, since once workflow_entity is deleted the workflow_history/execution_entity/shared_workflow get as well deleted (table and the history/execution tables is governed by a Foreign Key constraint with an ON DELETE CASCADE rule… I suppose).
