¿El webhook de TradingView no funciona? 8 causas habituales y una lista de comprobación

Configuraste una alerta en TradingView, pegaste la URL del webhook y luego… nada. O peor, la versión frustrante: a veces funciona y a veces no, sin un patrón claro.

He pasado por todo esto y he depurado muchos casos ajenos. La conclusión: el 90% de «el webhook no funciona» no es magia negra — cae en un puñado de causas fijas. Abajo van de más a menos frecuentes. Revísalas una a una y casi siempre encontrarás al culpable.

1. Tu plan de TradingView no incluye webhooks

La causa más común y la más fácil de pasar por alto. El plan gratuito (Basic) no admite webhooks — necesitas Essential o superior.

Cómo comprobarlo: al crear una alerta, baja a la pestaña Notifications al final del diálogo. Si no aparece la opción «Webhook URL», el problema es el plan — deja de depurar lo demás.

2. La URL no es HTTPS o usa un puerto raro

TradingView impone requisitos estrictos a la URL receptora. Rompe cualquiera y no sale nada:

• Debe ser https:// — http:// se rechaza de inmediato;
• Solo se aceptan los puertos 80 y 443 — una URL con otro puerto (p. ej. :3000, :8080) se rechaza;
• Sin IPv6 — el dominio debe resolver a IPv4;
• Sin direcciones locales — los servidores de TradingView no alcanzan localhost, 127.0.0.1 ni 192.168.x.x.

Si pruebas un script en tu máquina, esto casi siempre pica — asumes que funciona en local, pero TradingView no llega a tu equipo desde fuera.

3. La autenticación en dos pasos no está activada

Una trampa: TradingView solo permite alertas webhook en cuentas con autenticación en dos pasos (2FA) activada. Sin 2FA, la alerta puede negarse a guardar la URL del webhook, o guardarla y no enviar nunca. Activa 2FA primero en la seguridad de la cuenta.

4. Ves 403 / 401: tu propio servidor lo bloquea

Si ejecutas un script o servicio propio y ves 403 o 401 en el log de alertas, puedes acotar rápido:

• 403: el servidor «reconoce» TradingView pero lo bloquea. Suele ser firewall, comprobación CSRF o una lista blanca de IP sin TradingView. Los webhooks de TradingView vienen de un conjunto fijo de direcciones IP — añádelas a la lista.
• 401: falló la autenticación. Lo más probable es secret o token incorrecto/caducado, o el tema 2FA de arriba.

Orden de ataque: confirma que el secret coincide en ambos lados, que firewall/lista deja pasar a TradingView, y prueba el endpoint con curl directamente.

5. El timeout de 3 segundos: la causa oculta de caídas intermitentes

TradingView tiene una regla fácil de pasar por alto: tu servidor debe responder en 3 segundos o la entrega se marca como fallida.

Es la razón real detrás de la mayoría de los «a veces sí, a veces no». Tu servidor suele ir rápido, pero de vez en cuando se atasca — consulta lenta a la BD, llamada downstream, arranque en frío — cruza los 3 segundos y esa alerta simplemente se pierde. TradingView no la reintentará por ti.

El enfoque correcto: devolver 200 al recibir y procesar el reenvío de forma asíncrona en segundo plano. Este paso se omite constantemente en scripts caseros, y entonces empiezan las caídas esporádicas en periodos de carga.

6. El log muestra 4xx / 5xx: el problema está en el receptor

El panel de alertas de TradingView tiene una columna de estado del webhook; pasa el cursor para el error exacto. Lectura aproximada por código:

• 400: payload mal formado — JSON roto o campo obligatorio que falta. Pásalo por un validador JSON.
• 404 / 410: URL incorrecta o destino (p. ej. webhook de Discord) eliminado.
• 5xx: el receptor falló o tuvo un error transitorio — revisa sus logs.

Un truco útil: apunta temporalmente el webhook a un endpoint público de prueba como webhook.site. Si llega allí pero no a tu URL, el problema está al 100% en tu receptor, no en TradingView.

7. Formato del payload: texto plano vs JSON

Por defecto TradingView envía el cuerpo de la alerta como texto plano; solo si el campo Message contiene JSON válido adjunta application/json.

Si tu receptor solo acepta JSON pero escribiste una frase normal en Message, el parseo falla. Para plantillas de campos (symbol, action, price, etc.), usa JSON:

{
  "symbol": "{{ticker}}",
  "action": "{{strategy.order.action}}",
  "price": "{{close}}"
}

8. No se «perdió» — alertas «spam» o «fantasma»

Otra clase de problema: no «no llegó nada» sino «llegó demasiado» o «cosas que no debían»:

• Spam duplicado: la condición usa once_per_bar y dispara repetidamente antes de cerrar la vela. La mayoría de alertas de estrategia deberían usar once_per_bar_close (una vez por vela cerrada).
• Alertas fantasma / históricas: tras Bar Replay o un reinicio, se recalculan velas antiguas y aparece un aluvión de señales obsoletas.
• La misma alerta dos veces: en un tirón de red TradingView a veces reenvía la misma alerta; sin dedup en el receptor, la mandas dos veces.

Una lista de comprobación que puedes marcar

Ve en orden — la mayoría se resuelve en los primeros puntos:

1. ☐ ¿Plan Essential o superior? (aparece la opción Webhook URL en la alerta)
2. ☐ ¿Autenticación en dos pasos (2FA) activada en la cuenta?
3. ☐ ¿URL https:// sin puerto no estándar?
4. ☐ ¿URL de dominio público alcanzable, no localhost / IP privada?
5. ☐ ¿Probado con webhook.site — ¿llega? (sí → el problema es tu receptor)
6. ☐ ¿El receptor «devuelve 200 primero, procesa async después» para quedarse bajo 3 segundos?
7. ☐ ¿Autohospedado: firewall/lista deja pasar las IP fijas de TradingView?
8. ☐ ¿Message es JSON válido? (si el receptor espera JSON)
9. ☐ ¿El disparador es once_per_bar_close para evitar spam?
10. ☐ ¿Las alertas fallidas se reintentan y registran — o desaparecen sin rastro?

Mejor que depurar cada vez: un receptor que no se rompe

Los puntos 5–10 apuntan casi todos a la misma raíz: tu receptor (ese script/servicio de reenvío) no es lo bastante robusto. Un Worker de Cloudflare o script en VPS casero suele «funcionar», pero omite los detalles que deciden la fiabilidad — respuesta en 3 segundos, reintento al fallar, dedup y auditoría.

Eso es exactamente lo que cubre SignalTo: te da una URL receptora lista para usar — HTTPS incluido, respuesta instantánea (acepta primero, reenvía async, no choca con el límite de 3 segundos), dedup entrante automático, reintentos al fallar y registro completo de entrega por mensaje. Los ítems más duros de la lista, resueltos por ti.

Consigue una URL receptora estable gratis →