El disparador de Telegram dejó de recibir actualizaciones: sin ejecuciones a pesar del flujo de trabajo activo

Preguntas
1

El problema: A pesar de esto, enviar un nuevo mensaje al bot ya no activa ninguna ejecución. La pestaña Executions no muestra nuevas entradas — la última ejecución exitosa fue hace más de un día, antes de que comenzara a hacer cambios. He intentado:
• Desactivar/reactivar el flujo de trabajo varias veces, esperando entre cambios
• Crear una nueva credencial de Telegram con el mismo token del bot e intercambiarla en el nodo Trigger (la prueba de conexión es exitosa, pero no aparecen nuevas ejecuciones)
• Confirmar que el nodo “Send a photo message” tiene un Chat ID fijo que apunta al canal correcto (no un Chat ID dinámico)
Pregunta: ¿Hay alguna forma de verificar la URL del webhook actual/estado que Telegram ha registrado para este bot desde dentro de n8n, o requiere llamar directamente a la API getWebhookInfo de Telegram? Sospecho que el registro del webhook se quedó “atascado” apuntando a uno de los flujos de trabajo ahora desactivados, y reactivar el flujo de trabajo correcto no está obligando a Telegram a re-registrar el webhook. ¿Cómo puedo forzar que n8n re-registre el webhook de manera limpia?

2

Hola @Marcello1

Telegram permite solo una URL de webhook activa por token de bot. Si tienes múltiples flujos de trabajo usando el mismo bot, o si una activación anterior no se limpió correctamente, Telegram podría seguir enviando actualizaciones a una URL antigua o incorrecta.

Para ver exactamente qué ha registrado Telegram, crea un flujo de trabajo temporal con un nodo HTTP Request y configúralo de la siguiente manera:

  • Method: GET
  • URL: https://api.telegram.org/bot<YOUR_BOT_TOKEN>/getWebhookInfo
    • (Reemplaza <YOUR_BOT_TOKEN> con tu token de bot real, manteniendo la palabra bot antes de él.)
  • Authentication: None (el token está en la URL).

Qué buscar en la respuesta:

  • url: Este es el campo más importante. Verifica si esta URL coincide con tu URL de webhook de producción actual de n8n. Si apunta a un dominio antiguo, una IP local, o una instancia de n8n diferente, has encontrado el problema.
  • has_custom_certificate: Si estás usando certificados autofirmados, esto podría ser relevante.
  • pending_update_count: Si este número es alto, significa que Telegram está intentando enviar mensajes a una URL que no está respondiendo (probablemente la antigua).
  • last_error_message: Esto te dirá si Telegram no puede alcanzar tu instancia de n8n (p. ej., “Connection refused” o “SSL error”).

Actualmente no hay un panel integrado en n8n para ver el estado del webhook registrado en los servidores de Telegram. Para diagnosticar y resolver esto, debes seguir estos pasos usando el nodo HTTP Request de n8n.

Si la URL es incorrecta o está “atascada”, puedes forzar un reinicio siguiendo esta secuencia:

  1. Desactiva TODOS los flujos de trabajo en n8n que usen este token específico de Telegram. Esto evita que compitan por el registro del webhook.
  2. Limpia el webhook en Telegram: Crea otro nodo HTTP Request para llamar al método deleteWebhook.
    • Method: POST
    • URL: https://api.telegram.org/bot<YOUR_BOT_TOKEN>/deleteWebhook
    • Ejecuta esto una vez. Esto le dice a Telegram que deje de enviar webhooks completamente para este bot.
  3. Verifica el reinicio: Ejecuta nuevamente la solicitud getWebhookInfo del Paso 1. El campo url ahora debería estar vacío.
  4. Reactiva tu flujo de trabajo objetivo: Vuelve a tu flujo de trabajo deseado y alterna a Active.
    • Cuando activas un Telegram Trigger, n8n automáticamente envía una solicitud setWebhook a Telegram con su URL de producción actual.

¿Te ayuda?

3

¡Hola @Marcello1! ¡Bienvenido!

Una cosa que añadir en el post de @kjooleng antes de ejecutar esa secuencia. Usa deleteWebhook?drop_pending_updates=true en lugar de deleteWebhook sin más. Telegram ha estado encolando cada mensaje enviado a tu bot desde que se rompió, y si ese backlog sigue ahí cuando vuelvas a registrarte, se entrega todo de una vez. Con un día de mensajes encolados eso son muchas ejecuciones disparándose al mismo tiempo, y tu nodo Send a photo felizmente publicará cada uno de ellos.

También vale la pena leer last_error_message de getWebhookInfo antes de cambiar nada. Si dice algo como connection refused, SSL error o wrong response, entonces el registro nunca fue el problema, Telegram simplemente no puede alcanzar tu instancia. Borrar y volver a registrar no lo solucionará y estarás aquí de nuevo mañana.

Lo que me hace preguntarte, ¿qué cambios hiciste justo antes de que dejara de funcionar? Un cambio de dominio, un nuevo proxy o una renovación de certificado producirían exactamente esto, y el webhook se vería correctamente registrado todo el tiempo.

4

Hola @Marcello1
Al hacer clic en Execute step o Execute workflow en un Telegram Trigger mientras el flujo de trabajo está publicado, se cambia el registro de Telegram a la URL de prueba, y la URL publicada deja de recibir eventos hasta que publiques de nuevo. Eso coincide con el cronograma, ya que se rompió mientras estabas editando. Despublica el flujo de trabajo, haz tus pruebas en la URL de prueba y luego publica, o mantén un segundo token de bot de BotFather puramente para pruebas para que los dos nunca se sobrescriban mutuamente.
Una cosa sobre el diagnóstico: ejecuta getWebhookInfo unos 30 segundos después de publicar en lugar de inmediatamente. Hay reportes de que la URL se registra correctamente y luego se borra a sí misma segundos después, lo que desde el exterior se ve exactamente como un registro que nunca tuvo lugar.