TradingView Duplicate Alerts: Why Orders Fire Twice

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.

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.

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.

A blanket cooldown can make the log look tidy while discarding a legitimate close or scale-in. Likewise, identical messages are not automatically duplicates: a strategy may intentionally repeat a same-sized entry later. The correction should remove the extra instruction you identified, while preserving the next instruction the strategy actually needs.

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