My "When chat message received" node doesn't work

Describe the problem/error/question

Hi.
I have an N8N hosted in a Hostinger account.
When I try to execute a “When chat message received” node, it does absolutely nothing. No error messages, no green check mark to show that it tried… nothing at all. I tried opening the chat URL on my browser, it does open, at least, but there are no responses there either. I created an API on hostinger and set it up on N8N, but that didn’t solve the problem.
The thing is, I have another N8N account, outside of hostinger, and it works fine there, even though that version is completely outdated.
I tried looking for solutions online, but I still haven’t found anyone talking about this problem in specific. Has anyone else gone trough this?

What is the error message (if any)?

Please share your workflow

This is the one that doesn’t work (recreated from the one that does):

This is the one that does.

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): Hostinger
  • Operating system:

@Caike_Oliveira the logs show nothing executed, so the chat message isnt actually reaching n8n to fire the trigger, its not the workflow. on a self-hosted box like hostinger thats almost always WEBHOOK_URL not matching your real public url, so the chat request cant get back in. is WEBHOOK_URL set, and to what, your actual hostinger domain or something like localhost?

Based on what @achamm said, on Hostinger this is usually set through their n8n app’s environment variables panel not SSH, under your n8n instance’s settings/configuration section. Check what WEBHOOK_URL is set to there; it needs to match the exact URL you access n8n at (including https://).

One thing to check independent of that: is this workflow actually saved and toggled Active (top-right switch in the editor)? The Chat Trigger’s production URL only responds when the workflow is active, if you’re just opening the chat URL while the workflow is in draft/inactive state, you’ll get exactly this symptom (page loads, but messages go nowhere, no execution logged).

If it’s active and WEBHOOK_URL looks correct, try the “Open chat” button directly from inside the node rather than a manually copied URL, Hostinger setups sometimes proxy through a path prefix that the node’s own preview accounts for automatically but a manually-typed URL won’t.

Hi there.

Thanks for the replies, but, as it turns out, it had nothing to do with webhook.

The “n8n_encryption_key” was empty. I had to manually insert it inside the Hostinger terminal. I don’t know why it was created empty. All I know is that as soon as I did, my nodes started responding. Now I can move on to the next step.

Again, thanks for the replies. Finding out where to check for the webhooks was what, eventually, got me to “encryption_key”.

@Caike_Oliveira nice catch, that explains the silent failure perfectly. An empty N8N_ENCRYPTION_KEY means n8n can’t decrypt your saved credentials, so credential-backed nodes just fail with no error at all, exactly what you were seeing.

Worth locking in now that it works: keep that exact key permanent and back it up somewhere. If it ever changes or resets to empty again, every credential you’ve already saved becomes undecryptable and you’d have to re-enter them all. So make sure it’s pinned in Hostinger’s env settings rather than left to regenerate on a redeploy.

Hit this exact thing with the Chat Trigger and it drove me nuts because the chat page loads fine while nothing reaches n8n at all. The trigger only fires when the workflow is active and the chat posts to the production webhook URL, not the test one, so if you are on the test URL you get green but nothing every time. On self-hosted behind a reverse proxy it is usually worse: the proxy swallows the webhook and chat paths, or it drops the websocket upgrade, so the message never lands. Set WEBHOOK_URL to your real public URL, activate the workflow, and make sure the proxy forwards both the chat/webhook paths and websocket connections. Once those line up the responses started showing for me right away.