Almost every tutorial on TradingView webhook alert setup follows the same arc: create an alert, paste a URL into the webhook field, write a JSON message, hit save, done. That gets a webhook firing. It does not get you a webhook you can trust with real orders, and the gap between "fires once in testing" and "fires correctly every single time, for months, unattended" is exactly where most automated setups quietly go wrong.The three failure modes below rarely show up in a quick demo. They show up a few weeks in, usually during a fast market, usually at the worst possible moment — a duplicate order fired on a bar that repainted, an alert message timestamped for a candle that already closed, or an alert that fired correctly but landed on an endpoint that was down for ninety seconds. None of them are exotic. All three are fixable with a checklist you set up once.
A webhook, in general, is just an HTTP request that one system sends to another the moment something happens — instead of your receiving system having to repeatedly ask "did it happen yet," the sending system pushes the notification the instant the condition is met. MDN's overview of how HTTP requests work is a useful primer if the underlying mechanics are new to you — a webhook alert is, under the hood, an HTTP POST request with a body, sent to a URL you control.TradingView's version of this lets you attach a webhook URL to any alert condition. When the condition triggers, TradingView sends an HTTP POST to that URL with whatever message body you configured — typically a JSON payload describing the symbol, the action, and any parameters your receiving system (a bot, a bridge, or in QuantZee's case the automation pipeline connecting alerts to execution) needs to act on. The official reference for the exact request format and constraints is TradingView's own webhook alerts documentation, and it's worth reading in full once rather than relying on a secondhand summary, since TradingView updates the specifics of payload formatting and alert behavior over time.That one-line description — "sends a POST request when a condition triggers" — is also exactly where the three failure modes below come from. Each one is a case where "when a condition triggers" turns out to be more ambiguous, or less reliable, than it sounds.
The first failure mode catches people who built their alert around "Once Per Bar Close" thinking it's the safest, most conservative setting — which it usually is, except for one specific trap. If your underlying strategy or indicator uses any logic that can repaint — meaning a signal that appeared on the current, still-forming bar can later disappear or shift once the bar actually closes and historical data settles — you can get a condition that technically "triggers" more than once around the same bar, especially during data reconnects, chart reloads, or TradingView's own replay/backfill behavior.The practical symptom is a duplicate order: your execution system receives two webhook POSTs that both claim to be "the" signal for the same bar, and if nothing on the receiving end deduplicates them, you end up doubled up on a position you only intended to take once.
The second failure mode is subtler and shows up as orders that are technically correct but executed against stale context. TradingView alerts fire based on server-side evaluation of your chart's data, and the moment your receiving endpoint actually processes the POST can lag the actual candle close by anywhere from under a second to several seconds, depending on network conditions, how busy TradingView's alert infrastructure is at that moment, and how your own endpoint queues incoming requests.For a slower strategy that drift is irrelevant. For anything timing entries or exits around a specific candle close — which describes most expiry-day and intraday option-selling automation — a few seconds of drift between "when the candle actually closed" and "when your system believes it closed" can matter, especially if your downstream logic also pulls a live price quote at the moment it receives the webhook and assumes that quote reflects the candle close price. It usually doesn't, exactly.
The third failure mode is the one people assume "won't happen to me" until it does. Your receiving endpoint — a VPS, a cloud function, a local bridge process — goes down for a short window: a deploy, a restart, a brief network blip, a cloud provider hiccup. TradingView fires the alert during exactly that window. The POST request fails, or times out, or gets no acknowledgment.Critically, TradingView's webhook delivery does not guarantee automatic retries the way some messaging systems do — a failed delivery can simply mean the signal never reached your system at all, with no record on your end that anything was missed unless you're specifically watching for gaps. For a strategy designed to act on every signal, a silently dropped signal during a brief outage is functionally the same as a bug in your trading logic: a trade that should have happened, didn't, and nothing alerted you to the miss.
None of these three mitigations require new infrastructure if you're already running any kind of automated alert pipeline — they're mostly logging, a timestamp comparison, and a basic uptime check. What they require is treating "the alert fired" as a claim that needs verifying, not an assumption you can skip past once the webhook URL is pasted in and the first test alert goes through.
| Failure mode | Symptom | Core fix |
|---|---|---|
| Duplicate fires on repaint/replay | Same signal triggers twice, position doubled | Dedupe on timestamp+symbol+action at the receiving end |
| Timestamp drift vs candle close | Execution logic acts on a quote that doesn't match the signal's real timing | Embed bar timestamp in payload; compare drift on receipt |
| Endpoint briefly down | Signal silently dropped, no retry, no record | Independent uptime check + reconciliation against expected signals |
If you're setting this up for the first time, QuantZee's own guide to connecting TradingView alerts to a webhook walks through the base setup end to end, and the alerts setup documentation covers the specific payload fields and configuration options referenced above in more depth.
A webhook alert that fires once, correctly, during a five-minute test is not the same thing as a webhook alert you can trust unattended through a volatile expiry session three weeks from now. The gap between those two is almost always one of the three failure modes above: a duplicate signal from a repaint, a timing mismatch between when a candle closed and when your system believes it closed, or a brief outage that silently ate a signal with no record it ever happened. Building deduplication, drift checking, and uptime monitoring into your setup once — rather than discovering each failure mode the hard way — is the actual work behind "paste the URL into the alert box," even though no tutorial puts it in those words.
Not in a way you should rely on. If your endpoint is down or the request times out when the alert fires, the practical outcome can be a dropped signal with no automatic resend, which is why an independent uptime check and a reconciliation process matter — see TradingView's own webhook documentation for the current specifics of delivery behavior, since these details can change.
Include a unique identifier in the alert's JSON message — the bar's timestamp combined with the symbol and action is usually enough — and have your receiving endpoint reject any second message that matches a combination it's already processed within a short time window.
The alert condition is evaluated against the chart's data, but the actual HTTP request has to travel across the network and then wait to be processed by your endpoint, which introduces a small delay. For strategies where timing matters closely, that gap is worth measuring rather than assuming it's negligible.
For most automated execution, "Once Per Bar Close" is the safer default because it waits for the bar to actually finish before firing, which avoids reacting to values that can still change. The repaint-related duplicate-fire risk discussed above can still occur around bar close in specific repainting setups, which is why dedup logic on the receiving end is still worth having even with this setting.
Without a reconciliation process in place, you often can't tell after the fact — which is exactly the problem. Setting up a comparison between the signals your chart logic should have generated and what your endpoint actually logged, checked at least once per trading day, is the only reliable way to catch a miss close to when it happens rather than much later.
It can be, but reliability comes from the checklist in this article, not from the base setup alone. A webhook pipeline with deduplication, timestamp verification, and independent uptime monitoring behaves very differently under real market conditions than one that's only ever been tested with a handful of manual alerts in a calm market.