Your TradingView alert fired. The log says so. But the trade never appeared in MetaTrader. No error message. No notification. Just a missed entry — and price is already 40 ticks away.
This is the most common support request in webhook-based trading automation. Forums split into two camps: one blames TradingView (“webhooks are unreliable”), the other blames the EA (“your code is broken”). Both are usually wrong. The real answer is that the signal chain from alert to executed order has at least four failure points, and most traders only check one.
This article maps the entire chain — alert, webhook, cloud relay, terminal, broker — and gives you a specific diagnostic test for each layer. No guessing. No “just check the URL.” A real troubleshooting sequence you can run in under ten minutes.
Before jumping into reasons, understand the full path your signal travels:
Condition met → alert fires and logs the event.
TradingView sends payload to your webhook URL via HTTPS.
Receives, validates, records the signal. Must respond within 3 seconds.
EA in your terminal picks up the signal and sends the order to your broker.
A failure at any single point kills the trade silently. TradingView logs alert firing and webhook delivery status in separate columns — so an alert can show “fired” while the webhook column shows a delivery error. That green checkmark in the alert log only means the condition was met. It tells you nothing about whether the signal actually reached your terminal.
This catches more people than any technical bug, and the failure mode is beautifully simple: you can’t misconfigure an option that doesn’t exist.
On TradingView’s free Basic plan, the Webhook URL checkbox isn’t greyed out or hidden behind a paywall warning — it’s simply not in the Notifications dialog. Your options are App and Toasts, and that’s the whole list. The webhook isn’t failing to deliver. It was never there. And it’s hard to remember to check for a feature you’ve never seen.
Webhooks require the Essential plan or higher (see current pricing at tradingview.com/pricing).
There’s a second gate: two-factor authentication. According to TradingView’s official webhook documentation, webhook alerts are only allowed when 2FA is enabled on your account. Without it, the option may appear in your plan, but delivery will not work.
How to diagnose: Open your TradingView account settings. Confirm your plan tier is Essential or above. Then check Privacy and Security — confirm 2FA is active. If the Webhook URL field doesn’t appear when creating an alert, you now know why.
The webhook URL connects TradingView to your execution relay. One wrong character and the signal goes nowhere.
TradingView doesn’t validate the URL when you save the alert. It accepts anything — even a completely invalid address. The actual delivery attempt happens only when the alert fires. If the URL is wrong, you find out from the error in the alert log, not at setup time.
The technical requirements are strict:
When the webhook can’t be delivered, the error appears in the Webhook status column of your alert log. TradingView documents these error categories: timeout exceeded, URL unavailable or invalid, secure connection issues, and server rejects connection. TradingView does not publicly document its retry policy for failed webhooks — treat any non-2xx delivery as a lost signal.
Quick test: Temporarily replace your webhook URL with a request-inspection service such as webhook.site. Fire a test alert. If the test service receives the payload, TradingView’s side is working and the problem is your actual relay endpoint. If nothing arrives, the issue is your TradingView configuration.
The alert fires, the webhook delivers, but the receiving server ignores the message because the JSON is broken.
A missing closing brace, an extra comma after the last key-value pair, an unescaped quote inside a string — any of these makes the payload invalid JSON. When TradingView sends non-JSON content, it sets the Content-Type header to text/plain instead of application/json. Some execution platforms reject text/plain payloads and only process application/json.
Another common issue: TradingView placeholders like {{ticker}}, {{close}}, {{strategy.order.action}} that aren’t resolving. If you see literal {{…}} text in your alert log instead of actual values, the placeholder syntax is wrong or the alert condition doesn’t support that placeholder type.
How to diagnose: Open your Alert Log. Hover over the most recent fired alert to expand the full message body. Check if placeholders resolved to real values. Copy the message and paste it into any JSON validator. If errors appear, fix the message template in your alert settings.
For Pine Script users: alertcondition() accepts only a const string — you can’t use series variables inside it. Use the alert() function instead, which accepts series strings. Or use the alert_message parameter in strategy.entry() and strategy.exit() calls.
This is the one that silently kills automated setups during volatile sessions.
According to TradingView’s webhook documentation, the receiving server must respond within 3 seconds. If your relay needs to do any processing before returning a response — validating the signal, looking up account settings, connecting to a broker API — it can exceed that window.
When the timeout hits, TradingView cancels the request. The alert log shows “timeout exceeded” as the webhook status. The signal is gone. TradingView does not publicly document whether timeouts trigger a retry, so treat a timeout as a permanent loss.
During high-volatility periods — market open, NFP releases, rate decisions — TradingView’s own webhook dispatch can experience congestion. The alert timestamp in your log reflects when the condition was met, not necessarily when the webhook was dispatched. If you log receipt timestamps on your receiving end and see gaps, that’s dispatch-side latency — not something you can fix from your end.
How to diagnose: Add timestamp logging on your receiving server. Compare the alert log timestamp against the actual receipt time on your server. If you see consistent gaps, it’s either TradingView dispatch congestion or your server’s response time. If it’s your server — acknowledge the webhook immediately with a 200 OK, then process the signal asynchronously.
If you’re using a cloud-based copier rather than a self-hosted relay, this layer is handled for you. Cloud copiers like the TradingView to MT4 Trade Copier respond well inside that 3-second window — based on our internal measurements, our webhook processing completes in approximately 150 milliseconds.
The webhook arrived at the cloud relay. The relay validated it. But nobody is on the other end to pick it up.
This is the most common cause of missed trades that aren’t a TradingView problem at all. The Receiver EA needs to be running inside an active MetaTrader terminal, connected to the cloud server, attached to the correct chart. If any of these conditions fail, the signal has nowhere to go.
For webhook-based copiers: the Receiver EA polls the cloud server for pending signals. If it’s offline when the signal arrives, there’s no catch-up mechanism. Signals are processed in real time only. If the terminal reconnects after a disconnection, alerts that arrived during the outage will not be replayed or executed retroactively — this is documented behavior for Nordman Connector, and it applies to most webhook copiers.
How to diagnose: Check the Experts tab in your MetaTrader terminal. It logs every action the EA takes — connections, signal receipts, errors. A gap in log entries means the EA was offline during that window. Check the Journal tab for connection-related messages. Verify the EA icon on your chart: smiley face = active and permitted to trade; sad face or red X = AutoTrading disabled or trading permission missing.
Our guide on how to install and run an Expert Advisor in MetaTrader 4 covers the setup steps that prevent most of these issues. A VPS is strongly recommended for any automated workflow — a home PC has significantly lower uptime than a dedicated server, and every hour of downtime is a window for missed signals that can’t be recovered.
The signal arrived. The EA received it. It tried to place the order. The broker said no.
This is where MetaTrader’s error codes become essential. Every time OrderSend() fails, MT4 assigns a numeric error code. The most frequent ones in webhook-automated setups:
| Error Code | Description | Common Cause | Severity |
|---|---|---|---|
| Error 133 | Trade is disabled | Outside market hours, holiday halt, account type doesn’t allow EAs | Critical |
| Error 134 | Not enough money | Free margin insufficient for requested lot size | Critical |
| Error 131 | Invalid trade volume | Lot size below broker minimum or doesn’t match lot step | High |
| Error 130 | Invalid stops | SL or TP closer than broker’s minimum stop distance | High |
| Error 138 | Requote / Off quotes | Price moved beyond maximum slippage before order could fill | Moderate |
Most of these errors never produce a popup on screen. They’re logged silently in the Experts tab. If you’re not checking that tab, you’ll think the EA did nothing — when in fact it tried and was rejected.
How to diagnose: Open the Experts tab (View → Experts in MetaTrader). Search for error messages. Each code points to a precise cause in the MQL4 documentation. Also check: demo vs live account, investor-password (read-only) mode, and whether your broker restricts EA trading on your account type.
Your alert fired once. The trade went through. Then nothing — even though your strategy generated five more analytical conditions that same session.
The problem is the Trigger setting in TradingView’s alert dialog. The options and what they actually do:
How to diagnose: Open your Alerts panel. Click on the alert. Check the Trigger setting. If it says “Once Only” and you need ongoing signals — that’s the problem. Change it to “Once Per Bar Close” for strategy-based automation. If the alert shows “Stopped” next to the trigger, it already fired its one allowed time.
Use this to isolate the failure layer in under five minutes. Start at Layer 1 and work down — the first layer that shows a failure is your root cause.
| Layer | Where to Check | Symptom | Fix |
|---|---|---|---|
| 1 — TradingView Alert | Alerts panel → alert status | Alert shows “Stopped” or doesn’t appear | Check Trigger setting; re-create if “Once Only” |
| 2 — Webhook Delivery | Alert Log → Webhook status column | Error code in Webhook status | Fix URL, HTTPS, port, 2FA, plan tier |
| 3 — Payload | Alert Log → message body | Literal {{…}} in message; 400 error from relay | Validate JSON; fix placeholders |
| 4 — Cloud Relay | Relay dashboard / server logs | No signal received in relay logs | Go back to Layer 2; check relay response time |
| 5 — Terminal / EA | MT4 Experts tab | Gap in log entries; sad face icon | Enable AutoTrading; check EA properties; use VPS |
| 6 — Broker | MT4 Experts tab → error codes | Error 130, 131, 133, 134, 138 | Fix lot size, margin, stops, account type |
The diagnostic matrix above works after the fact. The real question is how to build a setup that catches failures before they cost you money. Three things matter: monitoring, redundancy, and architecture.
Monitoring: your execution relay should tell you when signals arrive and when they don’t. If you’re building your own, add logging. If you’re using a managed copier, check that it provides an admin dashboard with signal and execution history.
Redundancy: your relay must respond to TradingView within 3 seconds or the signal is lost. A cloud-hosted relay handles this by design. A VPS keeps your terminal running through local machine outages.
Architecture: the reason traders hit these issues repeatedly is that they’re bolting together disconnected tools — a TradingView alert, a self-hosted Python script, a locally-running MT4 on a laptop. Every junction is a failure point with no visibility.
Nordman Connector was built to collapse layers 4 and 5 into one monitored step. The cloud server receives the webhook, validates the signal, and records it in the dashboard. The Receiver in your MetaTrader terminal maintains a persistent connection to that server and executes the trade locally. If the Receiver loses connection, a Telegram notification fires immediately — so you know within seconds, not hours.
You can see the full execution flow in this walkthrough: TradingView to NinjaTrader in ~0.5 Second — Auto Trade Copier. The same cloud infrastructure handles MT4, MT5, and NinjaTrader 8 — details on connecting all three are covered in Can You Connect TradingView to MT4, MT5, and NinjaTrader 8?
For more on execution latency and when it actually matters for your workflow, see When ~0.5s Execution Actually Matters in Automated Trading.
This kind of webhook-to-terminal automation makes sense if you’re running TradingView strategies or indicator-based analytical conditions that need to execute on MT4, MT5, or NinjaTrader 8 without you sitting in front of the screen. Scalpers and intraday traders on prop firm accounts. Strategy developers who backtest on TradingView and execute elsewhere. Signal providers distributing to multiple terminals.
It doesn’t make sense if your strategy operates on daily or weekly charts and you have time to place trades manually — the automation overhead isn’t justified. It also won’t fix a losing strategy. If the analytical conditions are bad, faster execution just loses money faster. And if your broker is in a different region from the cloud infrastructure, execution latency may negate the speed advantage.
If that’s your situation, this article was useful for the diagnostics. Close the tab. Don’t spend €25/month on automation you don’t need.
Need something custom built? We develop automation to order → Forex EA Programming Services
Nordman Algorithms provides software infrastructure for trade automation and does not offer financial advice, trading signals, or managed trading services. This article is for informational and educational purposes only. Trading leveraged instruments such as Forex and CFDs carries a high level of risk and may not be suitable for all investors — only risk capital should be used. Full Risk Disclosure: https://www.nordman-algorithms.com/risk-disclosure/
