Telegram trigger problem (cloud)

Hello n8n community,
I’m experiencing a persistent issue with Telegram Trigger webhooks on my self-hosted n8n instance. Despite correct configuration, webhooks are not being registered in n8n’s internal database.
Environment
Hosting: Hostinger VPS with Docker
Domain: https://n8n.srv1181324.hstgr.cloud/ (publicly accessible with HTTPS)
Container: Docker using Hostinger’s Docker Manager
n8n version: Latest (docker.n8n.io/n8nio/n8n)
Problem
Telegram Trigger node returns 404 errors. Telegram successfully reaches my server, but n8n responds with:
text
The requested webhook “GET 997738c2-e41f-42d5-89be-9b098dd401c5/webhook” is not registered.
What I’ve Verified :white_check_mark:
Environment variables are correctly set inside the container:
text
WEBHOOK_URL=https://n8n.srv1181324.hstgr.cloud/
N8N_HOST=n8n.srv1181324.hstgr.cloud
N8N_PROTOCOL=https
N8N_PORT=5678
Telegram bot configuration is correct:
Cleared old webhooks via deleteWebhook?drop_pending_updates=true
Verified webhook URL is registered with Telegram
Telegram’s getWebhookInfo shows correct URL and pending messages
Network connectivity works:
Domain is publicly accessible via HTTPS
Telegram requests ARE reaching n8n (visible in logs)
Server responds to webhook URL (returns 404, not timeout)
What I’ve Tried :cross_mark:
Restarted n8n container multiple times
Deleted and recreated Telegram Trigger node
Created brand new bot with new token
Deactivated/reactivated workflows
Added N8N_SKIP_WEBHOOK_DEREGISTRATION_SHUTDOWN=true
Redeployed container via Docker Manager
Key Finding
When checking webhook logs:
bash
docker logs root-n8n-1 --tail 200 | grep -i “webhook”
Result: Returns EMPTY - no webhook registration messages at all, even when activating workflows.
When activating a workflow with Telegram Trigger, I see NO logs indicating webhook registration (no “Registered production webhook” messages).
Questions
Why would n8n not register webhooks to its database even with correct environment variables?
Could this be a database persistence issue? (Volume mounting problem?)
Is there an additional configuration needed for webhook registration in Docker?
Any help would be greatly appreciated. I’ve been troubleshooting this for hours and can’t figure out why webhooks aren’t being registered internally. been asked before, please follow the template below. Skip the questions that are not relevant to you. →

Describe the problem/error/question

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:
1 Like

Please send a screenshot of the telegram trigger

“had the same issue all off the sudden it stopped working and spend the whole weekend trying to figure this out, the issue is Telegram Blacklisted the hostinger urls, so you will have to add some new domain to it. I did it and now it work, i switched from hstgr.vloud to n8n.mydomain.com

Quoted from an answer out there…
Can’t confirm that is this, sinceni own a domain and subdomain and it works.

P.S try adding the env var N8N_PROXY_HOPS=1 then ensure your reverse proxy sends X-Forwarded-For, X-Forwarded-Host, X-Forwarded-Proto.

If this either doesn’t fix that, your docker config will be good to check before your proxy conf file.

Cheers!

Hi! This is a very detailed breakdown. Since your logs show no registration messages at all when activating the workflow, and you’re getting a 404 (not a timeout), the issue is likely that n8n is “losing” the webhook registration in memory or failing to write it to the internal database.

Here are the 3 most likely causes and fixes for this specific Hostinger/Docker setup:

1. The “Path Overlay” Issue (N8N_PATH)

Sometimes, depending on how the Docker Manager or Proxy is set up, n8n expects a subfolder or has a path prefix mismatch.

  • Check: Are you using the N8N_PATH environment variable? If it’s set to /, try removing it.

  • The Fix: Ensure your WEBHOOK_URL exactly matches the base URL. If your webhook URL in Telegram is https://n8n.example.com/webhook/123, but n8n is internally expecting https://n8n.example.com/n8n/webhook/123, it will 404.

2. Database Corruption or Locking (SQLite)

If you are using the default SQLite database and the Docker volume permissions are incorrect, n8n might be failing to write the “active” webhook to the webhook_entity table.

  • The Fix: Check your Docker volume permissions. Ensure the user inside the container (usually node with UID 1000) has write access to the /home/node/.n8n folder.

  • Test: Run docker exec -it <container_name> ls -la /home/node/.n8n and check if n8n.sqlite is owned by node.

3. Execution Mode vs. Production Mode

In n8n, Test webhooks and Production webhooks use different URLs.

  • The Error: If you are clicking “Listen for Event” in the UI, you must send the test message to the Test URL (which includes /webhook-test/).

  • The Fix: Once you click Activate (the toggle in the top right), n8n registers the Production URL (which uses /webhook/). If you are sending production traffic to a test URL, or vice versa, you will get that “Webhook not registered” 404.

4. Multiple Network Interfaces (Docker Bridge)

Sometimes n8n binds to an internal Docker IP that doesn’t align with the proxy headers.

  • The Fix: Try adding this environment variable to your Docker config: N8N_LISTEN_ADDRESS=0.0.0.0 This forces n8n to listen on all interfaces for incoming webhook registrations.

One quick question for you: When you look at the Telegram Trigger node settings, does the “Webhook URL” displayed at the bottom of the node match exactly what you see in getWebhookInfo from Telegram?

If they match and it still 404s, it is almost certainly a database write permission issue preventing the registration from sticking.

This usually points to persistence, not config.

If n8n isn’t logging any webhook registration events when you activate the workflow, that strongly suggests the webhook never gets written to the internal DB.

A few things I’d double-check based on similar cases I’ve seen:

  • Volume mounting: confirm the /home/node/.n8n volume is actually mounted and writable. If the container restarts without persistence, webhook registrations silently disappear.

  • Database mode: are you using SQLite (default) or an external DB? If SQLite, make sure the DB file lives inside the mounted volume, not the container filesystem.

  • Execution mode: if you’re running multiple containers or queue mode without workers aligned, webhooks can fail to register properly.

  • Base URL mismatch: ensure WEBHOOK_URL exactly matches what n8n believes is its public URL (no trailing slash inconsistencies, no proxy rewriting paths).

The fact that:

  • Telegram reaches the server

  • n8n responds with “webhook not registered”

  • and no webhook logs appear at all

is almost always a persistence or execution-context issue rather than Telegram or env vars.

I’d start by validating the volume mount first — that’s been the root cause in most Docker + VPS cases I’ve debugged.