I have a Telegram trigger node set up to wait for messages from a bot. The workflow is active, and when I send a message to the bot, the trigger fires, and the message gets processed—so everything works as expected… at first.
But after about 15-20 minutes, messages sent to the bot no longer reach n8n, even though the workflow remains active.
When I call the Telegram API (https://api.telegram.org/bot{{token}}/getWebhookInfo), I get this response: getWebhookInfo
Has anyone run into this before? Any ideas what might be causing it?
I’ve had a similar issue with the Webhook node.
I set up a simple Webhook to handle GET requests—it also works initially, but after some time, requests start returning a 404 (“handler not registered”) error. Webhook node
Never seen this before.
Oddly enough, I have another server running the same n8n version in Docker, and it works flawlessly there.
n8n works in docker. reverse proxy is configured. I have been working on these settings for the last few months. Everything was fine. But last week I started to notice that telegram bots work for a while, but then they start to fall off. As if telegram itself cannot send a webhook to n8n and records a 403 error. I do not understand how this can be. Why, when connecting a workflow, the bot works normally, but after some time n8n stops receiving webhooks. What can happen during this period?
I think I figured out what the problem is.
And this is probably another n8n error
Here’s the gist
There is a workflow. It has a telegram trigger node. The process is running and activated.
I copy this node, create a new workflow and paste the node into it.
Setting it up to work with another bot, change name. I save and activate second process. As a result, in the internal n8n database in the webhook_entity table, the trigger data from the first process will be overwritten by the data from the second process.
As a result, only the bot from the second process will work. And the first one, alas, has fallen off.
Why a separate identifier for the webhook is not created when copying/pasting a node is a mystery
Firstly, it is not at all obvious. There is a concept of a Full copy of an object - in fact, a clone, on the other hand - a new instance. It inherits some properties of the parent object, but it is an independent copy that lives its own life.
Secondly, it is really necessary to explicitly indicate when copying that a clone is being created and certain effects are possible.
Well, like I said improvements can be made but what is a requirement for somebody isn’t necessary for the other. You can always launch a feature request such a feature.