Duplicate TradingView webhook alerts and how to ignore them

[Fairman]

Duplicate TradingView webhook alerts and how to ignore them

Anyone who sends TradingView alerts to a broker through a webhook eventually sees the same alert arrive twice. Sometimes three times. If the receiving code treats each one as a new instruction, one signal becomes two or three positions.

There are a few causes. TradingView may resend an alert if it doesn't get a quick response from your server. An alert set to fire once per bar can trigger more than once if the condition flips on and off within the bar. And network retries between services can deliver the same message again.

The fix belongs on the receiving end. Every alert should carry something unique that the receiver can check. The simplest version is to include the symbol, the bar time and the signal type in the alert message. The receiver keeps a short list of recently processed keys and drops any message whose key it's already seen.

A few other practical points. Respond to the webhook quickly with a success code and do the actual order work after, so TradingView doesn't resend while you're still talking to the broker. Store the processed keys somewhere that survives a restart, even a small file, otherwise a server restart wipes the memory and duplicates get through again. Keep the list short, a day of keys is usually enough.

None of this is complicated, but skipping it is one of the most common ways a simple alert setup ends up with more exposure than intended.

For anyone using a third party bridge service rather than their own server, check whether the service already handles duplicates, since some do and some leave it entirely to you.

Send the same alert to your receiver twice by hand, using a tool like curl, and confirm that only one order reaches the demo account. Then restart the receiver and send it again to check that the memory of processed keys survived the restart.

[Fairman]

Keep the alert separate from the action when you design it. The alert says what happened, a long signal on EURUSD at the 10:15 bar for example. The receiver decides what to do with it, based on current positions. If a long is already open from that signal, a duplicate does nothing. If there's no position, the first message opens one. Thinking about it as desired state instead of a list of commands makes duplicates much less dangerous. Even if the key check fails for some reason, the position check catches it before a second order goes to the broker, so you have two layers rather than one.

[Fairman]

The once per bar close setting on TradingView is usually safer for automated alerts than once per bar or every time the condition is met. It only fires when the bar closes and the condition is true at that point, which removes most of the flickering duplicates from intrabar changes. The cost is that the signal comes at the end of the bar rather than the moment the condition is first met. For scalping on M1 or M5 that delay is often acceptable, given that it removes a whole category of problems that otherwise need extra code to handle properly.

[Fairman]

Logging every incoming webhook raw, before any processing, is very useful for debugging. Keep the full message body, the arrival time and the source IP if you have it. When something odd happens, such as a position you didn't expect, the log shows exactly what arrived and when. Without it, you're guessing whether the duplicate came from TradingView, from your server or from the broker connection. The raw log should be kept separately from your trade log, because it records what was received rather than what was done about it, and those two things can differ. Rotating the log file daily keeps it small and makes the right day easy to find. A week or two of history is normally all you'll ever need for this kind of debugging, and older files can be deleted on a schedule.

[FXS London Scalper]

Duplicate webhook alerts are a real risk. The simplest fix on the receiving side is an idempotency key: include a unique id in the alert message, for example the bar time plus the strategy name, and refuse any order with an id already seen. Timeouts on the server side cause many of the resends, so replying to TradingView immediately and processing the order afterwards also helps. Both are worth testing before the London open when alerts tend to fire close together.

[Fairman]

Security is part of the same problem. A webhook URL is effectively a public endpoint, and if someone else learns it they can send fake alerts. Including a secret token in the alert message and rejecting anything without it is a minimal step. It also helps to restrict accepted requests to TradingView's published IP addresses if your setup allows it. Duplicate filtering protects you from your own alerts being repeated. A token protects you from alerts that were never yours in the first place, which is a much worse thing to discover after the fact. Change the token if you ever share a screenshot of the alert setup or the server code, since it's easy to leak it without noticing.