A TradingView alert is a message, and a message isn’t an order. To become a trade, it has to leave TradingView as a webhook, reach another service within three seconds, get turned into an order and be accepted by your exchange. It can fail at any of those steps, and you may not be told.
TradingView says so itself: webhooks “may occasionally fail to reach the specified URL.”
Where the chain breaks
- The webhook can’t be sent. TradingView only allows webhook alerts when two-factor authentication is on, and they need a paid plan.
- The address is wrong. TradingView accepts only ports 80 and 443, and it doesn’t test the URL when you save the alert. You find out when the alert fires.
- The other service is slow. “If a remote server takes longer than three seconds to process a request, the request will be cancelled.” Treat a cancelled request as lost.
- The message is malformed. A stray character in the alert’s JSON can make the receiving service reject it.
- The exchange refuses the order. Too little balance, a size below the minimum or a wrong symbol name all stop the trade after the signal has arrived.
- The alert has stopped. An alert set to fire once fires once, then stays in your list looking active.
How to check what happened
Open the alert log and look at the webhook status for that alert. Then compare it with your exchange’s order history. A green tick in the alert log only shows that the alert fired. Your order history shows whether a trade happened.
How to make it fail less
- Have your receiving service answer TradingView straight away and do the work afterwards, so it stays under three seconds.
- Run the whole chain on paper first, and keep the logs from both ends.
- Get a notification when an order is rejected, so a failure doesn’t wait until morning.
Removing the chain
Each step exists because the strategy lives in one place and the order is placed in another. If the same system runs the strategy and places the order, there is no alert or webhook to lose. That’s how Pine Script runs in Tradenos.