TradingView Alerts Not Executing Trades? 5-Layer Fix

Your alert log shows a green checkmark. Your chart shows the entry. Your account shows nothing.

That gap is the most common support ticket in retail trading automation, and almost nobody diagnoses it correctly the first time. Traders assume the alert broke. But in our queue, the alert is the culprit less than a third of the time. The signal usually dies further down the chain, often at the broker, which never tells TradingView anything at all.

So this guide walks the whole path a signal travels, layer by layer, and gives you a fixed order to test them in. By the end you’ll know which of the five layers ate your trade, and what to change so it doesn’t happen again.

Key Takeaways

• Roughly 34% of “alert fired, no trade” cases die at the broker or prop firm, not inside TradingView.
• TradingView cancels any webhook that takes longer than three seconds to respond, and only retries on HTTP 5xx errors.
• Webhooks require 2FA, ports 80 or 443, and IPv4. Miss one and the alert fires but sends nothing.
• Diagnose top-down through five layers. Testing randomly is why this costs people days.

Why Are Your TradingView Alerts Not Executing Trades?

Because “fired” only means TradingView evaluated your condition and queued a notification. It says nothing about whether the message left TradingView’s servers, arrived intact, authenticated with your broker, or survived that broker’s risk checks. Five separate systems have to agree before a contract changes hands. And four of them can fail silently.

Here’s the chain, in order:

1. Pine Script logic. Your condition becomes true on a bar.
2. Alert configuration. TradingView decides whether to fire, based on frequency, limits, and expiry.
3. Delivery. TradingView POSTs your payload to a webhook URL.
4. Receiver-to-broker translation. Middleware parses the JSON, authenticates, and places an order.
5. Broker or prop firm execution. The venue accepts, rejects, or partially fills it.

So we pulled twelve months of execution-failure tickets from our own support desk. Then we sorted every one by which layer actually broke. The distribution surprised our engineers.

Read that chart the right way and it reframes the problem. Six out of ten failures happen after the webhook was already delivered successfully. So if you’re squinting at Pine Script trying to work out why your entry didn’t fill, you’re inspecting the layer least likely to be broken.

And for a primer on how alerts behave before you automate them, our introduction to TradingView alerts covers the fundamentals this guide assumes.

Layer 1: Did the Alert Actually Fire, or Just Look Like It?

Start here anyway. It takes ninety seconds to clear. Open the Alerts panel, click the alert name, and open the Log tab. Every fire event is stamped there with a timestamp, plus the HTTP response code the receiving server returned. No log entry means no fire, which is a completely different problem from a fire that got dropped.

Three things quietly stop alerts from firing.

Alert frequency. “Once Per Bar” triggers on the first tick where your condition is true, using live, still-forming bar values. But “Once Per Bar Close” waits for confirmation. So if your strategy backtests on closed bars while your alert runs on “Once Per Bar,” the condition can flash true mid-bar, fire, then reverse before the candle closes. Your chart shows no signal. Your log shows a fire. Both are correct.

Alert limits. Free accounts get a single active alert. Essential allows 20, Plus 100, Premium 400, and the top tier runs to a thousand of each type. Hit the ceiling and new alerts fail to activate, often without an obvious error.

Expiry. Alerts don’t live forever. On lower tiers they expire on a fixed schedule, and an expired alert sits in your list looking perfectly healthy while doing nothing at all.

From our support desk: the single most common one-line fix we send is switching alert frequency from “Once Per Bar” to “Once Per Bar Close.” In our experience it resolves the “my chart and my fills disagree” complaint outright, because it forces the alert to use the same non-repainting values your backtest used.

So if the log is empty, your problem is Layer 1 and you can stop here. But if the log has entries, keep going down.

Layer 2: Did TradingView Actually Send the Webhook?

About 13% of failed automations die right here, before a single byte reaches your server. An alert can fire and still send nothing. That’s because TradingView enforces five hard requirements on webhook alerts, and failing any one of them turns your automated strategy into a very expensive notification system.

The requirements, exactly as they’re enforced:

That last row deserves more blame than it gets. A trailing space after a pasted URL. An http where https was needed. A copied character that looks right but isn’t. Each one produces an alert that fires perfectly and delivers nothing.

TradingView also publishes the four IP addresses its webhook requests originate from: 52.89.214.238, 34.212.75.30, 54.218.53.128, and 52.32.178.7. So if your receiver sits behind a firewall, a VPS security group, or a WAF, those four addresses need to be allowed through. And this is the leading cause of “but it worked yesterday” failures right after someone tightens server security.

Here’s a connection most troubleshooting guides skip entirely. The HTTP response code in your alert log tells you which layer failed, and it’s the fastest diagnostic available to you. A 200 means delivery succeeded, so your problem lives in Layer 4 or 5. A 4xx means your payload or auth is wrong, so Layer 4. A 5xx means the receiver crashed. And a blank or timeout entry points at Layer 3. One glance at that column skips hours of guesswork.

Want to go deeper on payload construction? Then our guide to boosting TradingView alerts with custom tools and webhooks walks through message bodies that survive parsing.

Layer 3: Why Does the Three-Second Timeout Silently Kill Trades?

Because TradingView cancels any webhook request where the remote server takes longer than three seconds to process and respond. That budget covers everything: DNS resolution, TLS handshake, your receiver’s processing time, and the response write. Blow past it and the request is cancelled with no retry and no queue.

And the retry rules are narrower than most traders assume. If your receiver returns an HTTP status between 500 and 599, with 504 specifically excluded, TradingView resends after five seconds for up to three additional attempts. Every other failure mode gets nothing. Timeout? Dropped. Connection refused? Dropped. A 400 because your JSON was malformed? Dropped, silently.

Cold starts are the quiet assassin here. Serverless receivers, hobby-tier hosting, and self-built scripts on sleepy VPS instances routinely idle down between signals. So the first alert after a quiet stretch pays a one-to-two-second penalty just waking up. And during fast markets, that’s precisely the alert you needed most.

We’ve watched this play out dozens of times with traders migrating off a self-hosted webhook script. Their setup works flawlessly in testing, because they’re firing manual test alerts every few seconds and the server never sleeps. Then it goes live. It sits idle for forty minutes between real signals, and the first live entry of the session times out. They blame the strategy. But the strategy was fine. If execution speed is part of your edge, our comparison of low-latency algorithmic trading brokers covers what actually moves the needle.

So here’s the practical rule. Your receiver must acknowledge with a 2xx immediately, then do the broker work asynchronously. Anything that waits for a broker fill before answering TradingView is a timeout waiting to happen.

Layer 4: What Breaks Between the Receiver and Your Broker?

This layer accounts for 26% of failures in our data, and it’s the one traders have the least visibility into. The webhook arrived. The receiver returned a clean 200. And still no order exists. Four culprits cover nearly all of it.

The first row causes the most wasted hours, because a 200 looks like success. So check the exact field spec in the PickMyTrade documentation rather than reusing a payload you found in a forum thread.

Is there a fast test for this layer? Yes. Fire the same payload manually with a curl request or your receiver’s built-in test button. If the manual send also produces no order, then the problem is definitively here and not in TradingView.

Layer 5: Why Does the Broker Reject a Perfectly Good Order?

This is the biggest single bucket at 34%, and the most misunderstood. The order reached the broker. The broker looked at it, said no, then returned a rejection your middleware may or may not have surfaced. On Tradovate accounts, those rejection reasons cluster into a predictable pattern.

Notice that the top two causes have nothing to do with your code. Max position limits fire when your strategy tries to add to a position the account rules cap. That’s extremely common on funded accounts, where the contract limit scales with your balance. And “no quotes” happens when you send an order outside regular trading hours, or into a thin session where the venue has no two-sided market.

Prop firm accounts then add a further rule layer on top of the broker’s own. Daily loss limits, trailing drawdown thresholds, news-window restrictions, and scaling plans can each block an order the broker would otherwise accept. Every firm writes these differently, which is why our prop firm FAQ and the supported prop firms list are worth checking before you assume a technical fault.

Rejections also cluster in time. They rise around scheduled economic releases, when spreads widen and margin requirements move. So if your failures concentrate at 8:30 a.m. Eastern, you don’t have a bug. You have a market-conditions problem. Our breakdowns of rejected orders in futures trading and Tradovate order rejections specifically go through each error string and its fix.

How Do You Diagnose TradingView Alerts Not Executing Trades in Five Minutes?

Work top-down and stop at the first layer that fails. Most traders lose days because they test randomly, tweaking Pine Script, then the JSON, then the broker connection, changing three variables at once and learning nothing. So the order below is deliberate. Each step is cheap, and each one eliminates everything above it.

Two habits then prevent most repeat incidents. First, log both sides. Keep TradingView’s alert log and your receiver’s execution log timestamped, so you can line them up. Second, run one deliberate test order at market open each session before you trust the automation with real size. Thirty seconds of verification beats discovering a dead token at 2 p.m.

And for a wider view of building automation that survives contact with live markets, see our Tradovate automation and futures bots guide plus the general TradingView alerts troubleshooting guide.

Which Failure Layers Can You Remove Entirely?

Three of the five. That’s the honest answer, and it’s worth stating plainly, because no tool removes all of them.

Layers 1 and 2 stay yours. Nobody else can decide whether your condition should evaluate on bar close, and nobody else can enable 2FA on your account. But Layers 3, 4, and 5 are infrastructure problems. And infrastructure problems are solvable by not building the infrastructure yourself.

PickMyTrade sits in that middle position, and its design maps onto those three layers fairly directly. The timeout problem goes away first, because a cloud receiver that never cold-starts acknowledges TradingView immediately and processes the order in under 200 ms on our side. Your total round-trip still depends on the broker and the network. But the receiver stops being the thing that eats the budget. Layer 4 gets handled by keeping symbol mapping and session management per broker, with automatic contract rollover running underneath, so expired-instrument rejections stop arriving on their own quarterly schedule instead of yours. And Layer 5 becomes readable rather than solvable, which is the honest framing: brokers will still reject orders, but full alert logging with timestamp, execution status, and broker order IDs means you read the reason instead of guessing at it. Global risk settings and daily loss limits then sit in front of the broker as a second net, catching the size mistakes before the venue has to.

Supported venues include Tradovate, Rithmic, Interactive Brokers, TradeStation, TradeLocker, ProjectX, Match-Trader, and Tradier, alongside funded accounts at Apex Trader Funding, TopstepX, FundedNext Futures, and others. But note that MT4, MT5, DXtrade, and NinjaTrader aren’t supported, and prop firm automation policies vary. So confirm your firm’s current rules before going live.

Pricing runs $50 per month or $500 per year, with a five-day trial that doesn’t require a card. Full details sit on the pricing page. And if you’d rather ask a person which layer is breaking your setup, our team is reachable directly.

Frequently Asked Questions

Why does my TradingView alert say it fired but nothing happened?

“Fired” only confirms TradingView evaluated the condition and queued a notification. So check the Log tab for the HTTP response code. A 200 means delivery worked and the failure is downstream, in your receiver or at the broker, which covers about 60% of these cases.

Does TradingView retry a failed webhook?

Only partially. If your receiver returns HTTP 500 to 599, excluding 504, TradingView resends after five seconds for up to three additional attempts. But timeouts, connection refusals, and 4xx errors get no retry at all. The alert is dropped silently.

Why do my automated orders get rejected during news events?

Because spreads widen, margin requirements shift, and venues can go quote-less for brief windows. “No quotes available” accounts for roughly 25% of futures rejections, and rejection rates spike measurably around scheduled releases. Many prop firms also restrict trading in news windows outright.

Should I use “Once Per Bar” or “Once Per Bar Close” for automation?

Use “Once Per Bar Close” for entries. It evaluates on confirmed, non-repainting values that match your backtest. But “Once Per Bar” fires on the first true tick of a forming bar, so a condition can trigger and then reverse before the candle closes.

Do TradingView webhooks work on the free plan?

No. Webhook alerts require a paid subscription, two-factor authentication enabled on your account, and a destination on port 80 or 443 over IPv4. Free accounts are limited to a single active price alert, with no webhook option available.

How do I know if my broker rejected the order or never received it?

Compare your receiver’s execution log against the broker’s order history. A rejected order appears in the broker log with a reason string. But an order that never arrived appears in neither, which points at Layer 4, the translation between receiver and broker.

The Short Version

The alert is rarely the problem. Roughly 60% of “fired but didn’t execute” failures happen after the webhook was already delivered successfully, and the single largest bucket is the broker or prop firm rejecting an order it received perfectly well.

So diagnose in order. Alert log first, then HTTP status, then response time, then a manual payload test, then the broker’s own order history. Each step costs a minute and eliminates everything above it. Guessing costs days.

And if Layers 3 through 5 keep breaking, that’s an infrastructure signal rather than a strategy signal. Infrastructure is the part you can hand off. You can start a five-day trial without a card, or read more about who builds this first.

About the author. The PickMyTrade Team builds and operates the cloud execution layer that routes TradingView alerts to Tradovate, Rithmic, Interactive Brokers, TradeStation, TradeLocker, ProjectX, Match-Trader, and Tradier, along with funded accounts at Apex Trader Funding, TopstepX, and FundedNext Futures. The failure-layer distribution in this guide comes from twelve months of our own execution-failure support tickets. Technical specifications for webhook timeouts, ports, retry behaviour, and origin IP addresses were verified against TradingView’s published documentation in August 2026. Questions about a specific setup? Reach the team directly.

Disclaimer:
This content is for informational purposes only and does not constitute financial, investment, or trading advice. Trading and investing in financial markets involve risk, and it is possible to lose some or all of your capital. Always perform your own research and consult with a licensed financial advisor before making any trading decisions. The mention of any proprietary trading firms, brokers, does not constitute an endorsement or partnership. Ensure you understand all terms, conditions, and compliance requirements of the firms and platforms you use.

Also Checkout: Automate TradingView Indicators with Tradovate Using PickMyTrade