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:
- Pine Script logic. Your condition becomes true on a bar.
- Alert configuration. TradingView decides whether to fire, based on frequency, limits, and expiry.
- Delivery. TradingView POSTs your payload to a webhook URL.
- Receiver-to-broker translation. Middleware parses the JSON, authenticates, and places an order.
- 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.
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.
| Step | What to check | If it fails |
|---|---|---|
| 1 | Alert log has an entry for the expected time | Fix frequency, limits, or expiry (Layer 1) |
| 2 | Log shows HTTP 200 | Check 2FA, port, URL, firewall IPs (Layer 2) |
| 3 | Response arrived under 3 seconds | Warm the receiver, respond async (Layer 3) |
| 4 | Manual curl of the same payload creates an order | Fix fields, symbol map, token, rollover (Layer 4) |
| 5 | Broker order log shows the order | Read the rejection string (Layer 5) |
| 6 | Order shows as rejected, not missing | Check position limits, hours, prop firm rules |
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
