How to Prevent Duplicate TradingView Alerts From Firing

If you automate crypto trades, few things are more unsettling than watching one signal turn into two orders. You set up a clean strategy, the alert fires, and somehow the exchange receives the same instruction twice. Learning how to prevent duplicate TradingView alerts from firing is one of the most important steps in making automated execution trustworthy, because a single unwanted repeat can double your intended position size or open a trade you never meant to place.

Duplicate alerts usually come from a mix of TradingView settings, Pine Script behavior, and how your relay layer handles incoming webhooks. This guide walks through where duplicates come from, how to stop them at each stage, and how a well-designed execution layer catches the ones that slip through.

Why duplicate alerts happen in the first place

A duplicate is any moment where your strategy intends one action but more than one order reaches the exchange. It helps to separate the problem into two layers. The first is the alert layer: TradingView itself sends the same webhook more than once. The second is the execution layer: the webhook arrives once, but something downstream submits the order twice.

Most traders assume the problem is always on the exchange side. In practice, the majority of duplicates start inside TradingView — an alert configured to fire on every tick, a Pine Script condition that stays true across multiple bars, or two overlapping alerts pointed at the same webhook. Fixing duplicates means addressing both layers rather than guessing at one.

Configure the TradingView alert correctly

The single most common cause of repeated webhooks is the alert frequency setting. When you create an alert, TradingView asks how often it should trigger. The options include "Once Per Bar," "Once Per Bar Close," and "Only Once," among others. "Once Per Bar" can fire the moment the condition becomes true intrabar, which means a condition that flickers on and off during a candle can send several webhooks before the bar even closes.

For most automated strategies, "Once Per Bar Close" is the safer choice. It waits until the candle is finalized before evaluating the condition, so a signal that appears and disappears mid-candle does not generate a burst of alerts. This one change eliminates a large share of duplicates for strategies that are meant to act on confirmed bars rather than live ticks.

Also check that you have not created two alerts for the same condition. It is easy to set up an alert, forget about it, and add another later. Both will fire, both will hit your webhook, and the exchange will see two identical orders. Review your active alerts and remove any overlap.

Fix duplicates at the Pine Script level

If your alert uses a custom Pine Script condition, the way you write that condition matters. A condition that remains true across consecutive bars will keep triggering as long as it holds. If you want a single alert when a state first becomes true, detect the transition rather than the state itself — fire only on the bar where the condition crosses from false to true, not on every bar it stays true.

Repainting is another culprit. An indicator that recalculates historical values can produce signals that appear, vanish, and reappear, each one capable of sending an alert. Building your entry logic around confirmed, non-repainting conditions keeps the alert count predictable. If you are refining how your strategy emits signals, our guide on the TradingView alert message format shows how to structure the payload so each alert carries exactly the information your relay needs — including a field you can use to identify and dedupe repeats.

Add a unique identifier to every alert payload

Configuration reduces duplicates, but no alert setup is perfect. The reliable way to catch repeats is to give every intended trade a unique identifier and include it in the webhook payload. This is the same idea behind an idempotency key: a stable value that represents one specific action, so the receiver can recognize when it has already seen that action.

A practical approach is to build an identifier from the strategy name, the symbol, the action, and the bar time. Two genuinely different signals produce two different identifiers; a duplicate of the same signal produces the same identifier. Your relay can then treat the second arrival as a repeat and ignore it. We cover the underlying pattern in depth in our guide on using idempotency to prevent duplicate trades, which explains how a single key keeps one signal mapped to exactly one order.

Deduplicate at the relay layer

The final safety net lives in the execution layer that receives your webhook and talks to the exchange. Even with clean alerts and a unique identifier, network retries and platform quirks can deliver the same webhook twice. A robust relay keeps a short-lived record of recent identifiers and drops any request whose identifier it has already processed within that window.

This is where infrastructure earns its place. At SignalToExchange, incoming webhooks are deduplicated by idempotency key before any order is submitted, so a repeated payload collapses into a single order rather than two. Because the platform is non-custodial and connects through trade-only API keys, it can place that order on your behalf without ever holding your funds or having withdrawal access. You control the logic that decides when to trade; the relay makes sure one signal produces one order, and only one.

Securing the webhook endpoint matters here too. If your webhook URL is guessable, unwanted requests can reach it and look like duplicates or worse. Pairing deduplication with a signed payload, as described in our guide on securing a TradingView webhook with HMAC signing, ensures the relay only acts on requests that genuinely came from you.

Test your setup before trusting it with live funds

Before you rely on any of this with real capital, confirm it end to end. Trigger the alert on purpose, watch what your relay receives, and verify that a deliberate repeat is caught rather than executed. If you see unexpected repeats, isolate the layer: is TradingView sending twice, or is one webhook becoming two orders downstream? Testing on a paper or testnet setup first lets you provoke duplicates safely and confirm your defenses hold.

Best practices to keep alerts from duplicating

• Use "Once Per Bar Close" for strategies that act on confirmed candles, so intrabar flicker cannot fire repeat webhooks.
• Audit your active alerts and delete any that target the same condition or webhook more than once.
• Fire on transitions, not states in Pine Script, so a condition that stays true does not keep triggering.
• Avoid repainting logic in the signals that drive alerts, since recalculated history can emit phantom repeats.
• Attach a unique identifier to every payload so repeats are recognizable downstream.
• Deduplicate at the relay with a short idempotency window as a final safety net.
• Test deliberately by forcing a duplicate and confirming it is ignored before going live.

Frequently Asked Questions

Why does my TradingView alert fire multiple times per candle?

The most likely cause is an alert set to "Once Per Bar" with a condition that turns true and false during the candle. Each time the condition flips true intrabar, the alert can fire. Switching to "Once Per Bar Close" evaluates the condition only when the candle finalizes, which removes most of these repeats.

Can I stop duplicates without changing my Pine Script?

Often yes. Adjusting the alert frequency and removing overlapping alerts fixes many cases at the TradingView level. For full protection, though, adding a unique identifier and deduplicating at the relay catches repeats that configuration alone cannot, including those caused by network retries.

What is an idempotency key and why does it matter here?

An idempotency key is a stable value that identifies one specific intended action. When the same key arrives twice, the receiver knows it is a repeat and ignores the second request. In automated trading it is the most dependable way to guarantee that one signal maps to one order regardless of how many times the webhook is delivered.

Does deduplication slow down my orders?

No. Checking an incoming identifier against a short list of recently seen keys is a fast, in-memory lookup that adds negligible latency. It runs before the order is submitted, so legitimate signals still reach the exchange quickly while repeats are dropped.

Bringing it together

Duplicate TradingView alerts come from three places: alert settings that fire too often, Pine Script conditions that keep triggering, and downstream delivery that repeats a webhook. Address each layer — choose "Once Per Bar Close," fire on transitions, attach a unique identifier, and deduplicate at the relay — and one signal will reliably produce one order. To see how deduplication works on non-custodial, trade-only infrastructure that keeps your funds on your own exchange, request access or start your free trial with SignalToExchange.

Automated trading involves risk. SignalToExchange is execution infrastructure and does not provide financial advice, trading signals, or guarantees of any kind.