Live published workflows not triggering

Questions
1

Describe the problem/error/question

I’m seeing issues with live published workflows not triggering. I have noticed that this tends to be happening alot.
I notice that this issue seems to happen when behind on the latest stable version of n8n.
Once I update to latest version, the workflows seem to come to life again (but could be due to restart), but this is causing alot of Prod issues.
Workflows are effectively just not listening to triggers causing manual intervention to get them going again.

What is the error message (if any)?

There are no error messages

Please share your workflow

Share the output returned by the last node

Information on your n8n setup

  • n8n version: 2.9.2
  • Database (default: SQLite):
  • n8n EXECUTIONS_PROCESS setting (default: own, main):
  • Running n8n via (Docker, npm, n8n cloud, desktop app):
  • Operating system:
1 Like
2

@simonBa Yes you are right i was also facing this issue when triggers like webhook, telegram and SMTP were working but skipping some executions but when i have restarted my n8n instance everything started working pretty well in the latest stable version, i am on cloud!

1 Like
3

Yes a restart fixes it, but this is not acceptable for a “Prod” Live environment where workflows should be always available. I’m also running cloud.

1 Like
4

Hi @simonBa

if a workflow processes a massive array or large file all at once, it spikes the container ram. the server silently kills the process to protect itself, which leaves your triggers totally unresponsive until the next restart.

check your instance dashboard for memory spikes right before the workflows stop. if the ram is maxing out, dropping a Loop node into your heavier workflows to process data in smaller chunks usually stabilizes it.

since it’s a prod cloud instance, honestly just ping the support chat in your dashboard. they can check the actual backend logs and tell you immediately if your container is throwing OOM errors.

adding a small “self-healing + monitoring” layer using the Public API While this doesn’t fix the root cause, but you can reduce manual intervention.

1 Like
5

@simonBa This usually does not happen but i recommend switching to self hosted n8n if your workflows are going to get used in production.

1 Like
6

Adding another angle here that hasn’t been covered yet:

Root cause #2: Webhook de-registration on process shutdown

In n8n, when the main process stops (update, crash, or container restart), it tries to de-register all webhook listeners. If the shutdown completes before re-registration happens, your webhooks end up in a “dead” state - the URL exists in the DB but n8n isn’t actively listening.

Fix for self-hosted (Docker/npm):

Set this environment variable to prevent de-registration on shutdown:

N8N_SKIP_WEBHOOK_DEREGISTRATION_SHUTDOWN=true

This way webhooks remain active after restart without needing a manual re-save.

For cloud users: A quick workaround:

  1. Open the workflow in editor
  2. Click Save (even without changes)
  3. Toggle the workflow OFF then back ON

This forces the backend to re-register the webhook listener.

Check execution mode:

Also verify your EXECUTIONS_PROCESS setting. If set to main but you have high-load workflows, consider switching to own mode so each execution gets its own process and a crash won’t take down the trigger listener:

EXECUTIONS_PROCESS=own

Hope this helps narrow it down!