TradingView Duplicate Alerts: Why Orders Fire Twice and How to Prevent Them

Two buy orders appear in the account. The chart shows one signal. Before changing the strategy, find out what happened twice: the alert event, the webhook delivery, or the instruction reaching the account. A second order is evidence; it is not yet a diagnosis.

For a TradingView-to-AlgoWay setup, compare the TradingView alert log, AlgoWay Webhook Logs, and the destination's order history over the same interval. Count events and requests separately. One chart marker is not a reliable count of either.

New: AlgoWay has optional Prevent Duplicate Alerts protection that filters byte-for-byte identical incoming instructions, including exits and modifications, on a per-webhook time window.

Find the first place the count doubles

Use one symbol, one account and a common timezone. Compare the action and quantity as well as the timestamp. “Buy” followed by “close” is a different sequence from two identical buy instructions.

The aim is to find the first boundary where one intended instruction becomes two. Counting only the final account rows leaves every earlier possibility open.

One strategy alert can listen to two event sources

A TradingView strategy alert can include order fills, explicit alert() calls, or both. If both sources describe the same intended entry, selecting both can produce redundant instructions. This does not require two active alerts.

Match the event selection to the script's message design. With order messages supplied through alert_message, select order fills and use {{strategy.order.alert_message}} in the message field. With JSON generated by alert(), select that event source. TradingView documents these choices in its Pine Script alert guide; the AlgoWay Pine Script examples show both setups.

Also check for an older active alert targeting the same route. Renaming the new alert does not tell you whether the old one is still running. Compare the actual active entries, including their symbol, timeframe and intended message.

For explicit calls, alert.freq_once_per_bar permits the first call in each realtime bar; it does not deduplicate webhook deliveries or govern order-fill alerts. Choosing bar-close frequency changes signal timing. It is not a general duplicate-order switch.

If the problem is an alert that has stopped after excessive activity, use the separate triggered-too-often troubleshooting guide. A stopped alert and a duplicate instruction are different failures, even when a noisy script causes both.

A single trigger can be delivered again

TradingView's webhook resubmission policy specifies retries when the receiver returns an HTTP status from 500 through 599, excluding 504. It retries after five seconds, with up to three resends: at most four sends for one trigger.

That is a specific rule, not a promise that every failed delivery will be retried. A pair of requests five seconds apart is a clue to check the response status, not proof of the cause.

Consider a hypothetical receiver that passes an order onward and then returns HTTP 500. TradingView's resend would deliver the instruction again even though the first attempt may already have affected the account. This illustrates why a delivery error cannot establish that no trade occurred; it is not a claim that AlgoWay handles every error this way.

Before manually resending a failed-looking alert, inspect the destination account and the matching AlgoWay processing result. Do not treat “retry” as a harmless synonym for “check.”

Work through one AlgoWay incident

Suppose the intended action is one buy instruction with quantity 1. These are illustrative records, not a support conversation:

1. TradingView: record the alert name, event time, message and webhook status. Check the interval for other alerts sending the same action.
2. AlgoWay Webhook Logs: locate each matching received message. Compare symbol, action, quantity and processing result. Keep separate records separate even if their JSON is identical.
3. Destination history: identify the corresponding orders, their status and resulting exposure. A received request is not proof of a filled order.

If TradingView shows two buy events and AlgoWay records two matching requests, start with the event selection and active alerts. If TradingView shows one event but AlgoWay records matching requests at 12:00:00 and 12:00:05, investigate delivery status and other possible senders. Do not change the strategy's entry condition merely because those timestamps resemble the retry interval.

If the records instead show one received request and two distinct accepted orders, preserve that evidence for support. Include the timezone, symbol, actions, quantities and response text through an appropriate private support channel. Redact credentials, account identifiers and webhook URLs from anything shared publicly.

Prevent Duplicate TradingView Webhook Alerts with AlgoWay

Most advice about duplicate trades concentrates on chart settings: delete a second alert, use once-per-bar-close, or avoid triggering both alert() and a strategy order-fill alert. Those fixes matter, but they cannot identify every repeated webhook delivery. TradingView's official resubmission policy permits up to three retries after qualifying 5xx responses, five seconds apart. An execution system also needs an optional way to recognize a message it has already seen.

AlgoWay's Prevent Duplicate Alerts is that receiver-side layer. It runs before the destination trading operation, and is off by default. It does not ban subsequent BUY trades merely because a long position is already open, or attempt to infer what a Pine Script strategy intended. It checks for the same incoming instruction repeated on the same webhook within a configurable interval.

How exact-payload deduplication works

1. When a webhook has protection enabled, AlgoWay calculates a SHA-256 fingerprint from the original raw request bytes.
2. It looks in the existing Webhook Logs for a recent record with the same webhook UUID, mapped symbol and payload fingerprint.
3. If it finds a matching message inside the configured interval, it skips the new attempt before forwarding it to the broker.
4. The skipped request appears in the ordinary Webhook Logs with status Error; click See error to read the explanation and the previous matching log reference. The HTTP response is 200 to acknowledge the intentional skip rather than trigger another retry.

The check applies to all order actions: buy, sell, flat, close, modify, breakeven and other processed alerts. Duplicate closing instructions are not exempt. Likewise, an earlier execution error does not automatically exempt a later identical message from the time-window check.

Matching is byte-exact, not semantic. Even a whitespace change, different JSON key order, a changed timestamp or a new random ID alters the fingerprint. Two messages may describe the same order yet pass independently if their raw bodies differ. Conversely, two intentionally identical commands arriving in the selected window are treated as repeats. That trade-off should be considered when designing alerts.

Real-world example: repeated BUY and repeated FLAT

The labels above stand for complete JSON webhook bodies; byte-for-byte identity is checked on the full original payload, not just the symbol and action. The window is checked against recent matching log records, including skipped attempts, so continuous identical repeats can keep the suppression active.

Enable the setting in your webhook

1. Open your AlgoWay Dashboard and choose Edit Webhook.
2. Under Advanced Settings, turn on Prevent Duplicate Alerts.
3. Set Duplicate alert window (seconds). The default is 10 seconds; you can choose from 1 to 86,400 seconds.
4. Click Save Changes. Configure each other webhook separately if necessary.

This feature is available to supported incoming webhook sources, including TradingView, Telegram and MT5-related routes. It should not be confused with the separate Telegram Copier Duplicate Protection rule described in the Telegram Copier troubleshooting guide.

Duplicate-message filtering vs same-direction protection and trade locking

Trading platforms use different mechanisms to address unwanted extra trades. PickMyTrade's same_direction_ignore is a position-direction rule: it can ignore a new BUY when a BUY position is already open. This can be useful for a one-position strategy, but it might also reject a legitimate scale-in. By contrast, TradersPost's trade locking serializes submissions for a broker account and symbol; it is not simply a filter for identical payload bytes.

AlgoWay's new option is distinct from both: it checks whether an exact original webhook message was seen on the same route inside the window. A second deliberate BUY with different JSON can pass even while a position remains open. For broader context, read why blocking repeat trades can break pyramiding strategies.

How many seconds should you use?

There is no universal perfect timeout. A 5-second window targets very close repeats, but may miss later attempts. 10 seconds is AlgoWay's default starting point. 30–60 seconds can suppress longer bursts but also raises the chance of blocking an intentionally repeated instruction. Use a demo account to test your strategy's actual timing and broker responses.

One trade-off deserves particular attention: if the first broker order fails and you send exactly the same instruction again inside the configured window, that later attempt can be suppressed. This is message-level duplicate protection, not a statement that the first order succeeded. Also, the check is per webhook UUID; it is not an account-wide constraint across independent URLs or a guarantee of exactly-once execution at the broker.

Frequently asked questions

Why does TradingView send two alerts for one trade?

Possible causes include multiple active alerts, indicator conditions firing intrabar, combined strategy order-fill and alert() events, and documented webhook retries. Compare the alert history and the receiver's logs. The official Pine Script alerts reference explains the event types and frequency choices.

Can AlgoWay prevent duplicate FLAT or CLOSE alerts?

Yes. The webhook-level feature checks identical incoming messages for all actions, including FLAT, CLOSE, MODIFY and BREAKEVEN.

Will it block every second BUY on the same symbol?

No. Only an identical original request body on the same webhook and mapped symbol, within the configured window, is treated as a duplicate. The filter does not impose a permanent one-position-per-symbol rule.

Do dynamic timestamps or JSON formatting changes matter?

Yes. A new timestamp, extra whitespace or different field order changes the SHA-256 fingerprint of the raw message, so two otherwise similar trading commands may no longer match.

Where can I see a blocked duplicate?

Open Webhook Logs and select See error on the rejected alert. The message identifies the duplicate and the configured time window.

Does the filter prevent every possible duplicate broker order?

No. It prevents repeated matching incoming webhook messages on the protected route. It does not cancel previously placed orders, merge independently configured webhooks or guarantee the outcome of a broker request.

Verify the fix without hiding a valid exit

Test the corrected setup on a demo account with one active alert path. Observe a fresh entry and its intended exit. Confirm that each expected event produces the expected request and account result. If you replaced an alert, make sure its predecessor is no longer active; the alert settings update guide covers that replacement workflow.

Exact-message filtering is a configurable trade-off: a deliberate identical close, modification or scale-in inside the window is suppressed too. Choose a suitable interval or disable the filter for a route requiring rapid identical commands. The correction should remove unwanted repeat instructions without breaking the strategy sequence.

Finish by checking open positions and pending orders against the intended state. Fixing tomorrow's alert does not remove yesterday's extra order.