TradingView Alert Not Working? Find the Point Where the Signal Died

"My TradingView alert is not working" almost never means what it says. It usually means a trade you expected did not appear, and the alert is the first thing in the chain you thought to blame.

The chain has five links, and each fails with a different symptom. None of them announces the failure loudly, because every link is built to skip quietly and let the next signal through. So the fix is not to change settings until something works. It is to find the link where the signal stopped, then touch only that.

Each step below starts with what you can observe, because that is all you have.

The one-minute split

Open two things side by side:

1. TradingView's alert log (the Alerts panel, alert log tab). Did the alert trigger when you expected?
2. The Trade Queue on your NexumTrader dashboard. Is there an entry for that moment?

Three outcomes, three destinations:

• No log entry: the alert never fired. Step 1.
• Log entry, no queue entry: the alert fired, the message never arrived. Step 2.
• Queue entry, no trade: the message arrived and died on the way to the broker. Steps 3 to 5.

The Trade Queue polls every three seconds and shows the newest 30 entries, so give it a moment, and switch the view selector to the one that includes skips and rejections. The default view hides exactly the entries you are looking for.

Step 1: the alert never fired

You see: nothing in the alert log at that time. No notification, no webhook status, no row.

This is not a bridge problem, and no amount of MT5 configuration will help. Four causes, in rough order of how often they explain "it worked for weeks and then stopped".

The alert expired. TradingView caps alert lifetime: "The maximum lifetime of an alert is two months. However, for Premium and Ultimate plans, the open-ended option is available" (Introduction to TradingView alerts). The plan comparison lists the duration as one month on Basic, two months on Essential and Plus (TradingView pricing). Expiry is silent.

It fired too often and was stopped. TradingView halts an alert that exceeds "no more than 15 triggers in 3 minutes" (Alert was triggered too often and stopped). The same ceiling applies to script alerts: "If a script alert triggers more than 15 times within three minutes, it automatically stops" (Alerts on alert() function). One noisy session can take an alert down and leave it down.

It was deactivated for age. TradingView deactivates an alert when all three are true at once: created more than a year ago, not triggered for over a year, not edited for over a year.

The condition was never true. If the frequency is anything other than Once Per Bar Close, the alert can fire mid-bar, and indicator values that depend on high, low and close keep moving while the bar builds. An indicator can cross a threshold during bar construction and shift back before the bar closes, which produces both alerts that look unwarranted on the chart and alerts that arrive later than the price action suggests (Issue with "Once Per Bar" alert). Pick the frequency deliberately: it decides when the signal leaves TradingView.

One mechanical trap: if the condition lives in a Pine script that calls alert(), the alert must be created against that script with Any alert() function call selected in the Condition field. With alert(), "the triggering frequency and the message are determined by the script's alert() calls, not by the dialog settings", so the dialog's frequency dropdown will not save you.

Step 2: the alert fired, the webhook never arrived

You see: a row in the alert log, nothing in the Trade Queue.

The alert log has a webhook status column, and it names the failure for you. TradingView documents the statuses and what each means (What do errors mean when sending webhooks):

• 4xx, "the server rejected it due to problems with the parameters, data, or access": your payload or your URL.
• 5xx, "the receiving server was unable to process it": the receiving service.
• Timeout exceeded, "the receiving server didn't respond to the request within 3 seconds".
• URL unavailable or invalid, "couldn't find this domain / the server couldn't be reached".
• Secure connection issues, usually a URL pasted as http:// instead of https://.

If the column is empty and nothing went out at all, three settings disable webhooks silently:

• The Webhook URL box is unticked in the alert's Notifications tab. Editing an alert's condition and re-saving is a common way to lose it.
• Two-factor authentication is off. TradingView is unambiguous: "For your data protection, webhook alerts are only allowed when 2-factor authentication is enabled" (How to configure webhook alerts).
• The plan does not include webhooks. TradingView's launch announcement calls the feature "available to paid users only" (Alerts can now be sent to 1000s of apps). The help centre article names no tier, so the current pricing page is the only reliable place to check your own plan.

Three constraints from the same help article catch self-hosted endpoints in particular: only ports 80 and 443 are accepted, IPv6 is not supported, and the receiving server has three seconds to respond. TradingView also publishes the four IPs it posts from (52.89.214.238, 34.212.75.30, 54.218.53.128, 52.32.178.7) for anyone maintaining an allowlist.

One retry behaviour is worth knowing before it surprises you. If the endpoint returns a 5xx status other than 504, TradingView resends after five seconds, up to three additional attempts. A slow or half-broken endpoint that eventually succeeds can therefore turn one alert into more than one instruction, which is an argument for pointing alerts at a service that answers immediately and queues the work rather than one that does the slow part first.

Step 3: the payload arrived, the dashboard did not act

You see: an entry in the Trade Queue, no trade, usually with a reason attached.

This is the step where the system is most talkative, so read it. In the view that includes skips and rejections:

• stale_dashboard_id: the alert carried a dashboard ID that no longer exists. Recopy the current one from the Overview page into the alert message.
• outside_trading_window: the signal arrived outside that account's schedule. See Trading Windows. Exit signals (close, closeall) bypass this check by design, entries do not.
• account_not_connected: no EA was polling for that account. That is step 4.
• no_eligible_account: nothing matched, usually the symbol.

If there is no reason and the entry simply failed, look at the payload. NexumTrader parses a single comma-separated line, not JSON, and tp and trail are mutually exclusive. The full grammar is in the webhook payload reference.

Step 4: the signal was queued, no EA picked it up

You see: the entry sits at Pending, then fails with "Trade timed out (not picked up within 5 seconds)". This is "why is my EA not taking trades", seen from the dashboard side.

The two timeouts mean different things. Nothing claimed within five seconds means no EA was listening. Claimed but silent for thirty seconds means an EA took it and lost the connection, so a position may exist at your broker. Check the terminal before resending that one.

Work down these in order:

1. The WebRequest allowlist. MT5 blocks outbound requests that are not on the terminal's allowlist, and since the EA never receives a response, it cannot report the failure: the account simply never comes online and the Experts tab logs error 4014. In MT5: Tools, Options, Expert Advisors, tick Allow WebRequest for listed URL, add https://api.nexumtrader.com, restart the EA. EA versions before 1.6.8 used a different host, so an EA that worked before an upgrade fails here until the new URL is added (error 4014).
2. Algorithmic trading is off. Both switches matter: "Allow algorithmic trading" in Tools, Options, Expert Advisors, and the AutoTrading button in the toolbar. The smiley face on the chart's EA icon is the confirmation.
3. The EA is not on a chart of that symbol. One terminal holds many charts, and only the chart whose symbol matches takes the signal. An EA on EURUSD will not take an XAUUSD signal. All four eligibility checks are in the signal flow reference.
4. The account is offline. The EA polls once per second and the dashboard marks an account offline after ten seconds without a heartbeat. If the card is grey, nothing further down this list matters yet.
5. The terminal is not running at all. The quietest failure of the set: the laptop sleeps, the terminal closes with it, TradingView keeps firing, the dashboard keeps queueing, nothing executes. If the failures track your own schedule rather than the market's, read do you need a VPS for MT5.
6. The terminal is logged into a different account. The EA reports whichever account the terminal is logged into. If that is not the registered one, you get "Account not found" instead of a trade.

Step 5: the order reached the broker and was rejected

You see: a numeric code, for example OrderSend failed: 10016.

At this point the whole chain works and the broker declined, so the fix is on the account or the symbol, not in TradingView. The number is the broker's return code; the text after it is the broker's own comment, which varies between brokers.

The one that is not really a broker problem is the symbol name. It must match the broker's Market Watch entry exactly, and brokers disagree about names for the same instrument (XAUUSD against GOLD, suffixed variants like EURUSD.m). A symbol that does not resolve reads as an alert problem from the outside.

The rest are ordinary account conditions: invalid stops, insufficient free margin, market closed, an unsupported filling mode, a volume outside the broker's limits, or auto trading disabled at the server. Each code is covered in the MT5 error code reference.

The ladder in one table

The plan limits that stop alerts quietly

A real share of "my alert stopped working" reports are plan limits behaving exactly as documented. From TradingView's published comparison:

• Active price alerts: 3 on Basic, 20 on Essential, 100 on Plus, 400 on Premium, 1,000 on Ultimate.
• Active technical alerts on indicators, strategies and drawings: none listed on Basic, then 20, 100, 400 and 1,000. If your condition lives in a script, this is the row that applies to you, not the price-alert row.
• Alert duration: one month on Basic, two months on Essential and Plus, open-ended on Premium and Ultimate.

Add the 15-triggers-in-3-minutes ceiling and the fact that webhooks are paid and require 2FA, and the pattern is consistent: on the lower tiers an automated setup has a shelf life measured in weeks unless someone renews it deliberately. Put a reminder against the expiry date, or budget for the tier that removes it.

Why is my EA not taking trades?

Asked from the terminal, this is the same question with one extra answer the dashboard side does not surface: the EA may be working perfectly and receiving nothing.

So before reinstalling anything, check whether a signal ever reached the queue. Nothing in the Trade Queue at that time means the EA is not the fault and steps 1 to 3 are where to look. An entry that timed out at five seconds means it is, and step 4 is the list.

The test that separates the two takes a minute: send a manual trade from the dashboard to that account, which skips TradingView and the webhook entirely.

• Manual trade executes, alerts do not: the terminal is fine, the fault is upstream.
• Manual trade also fails: the fault is in the terminal, and the WebRequest allowlist is the first thing to check.

One caveat: a manual trade blocked by a trading window produces no queue row at all, only a message at the time of sending, so an empty queue after a manual send is not automatically bad news.

FAQ

My alert worked for weeks and then stopped on its own. Why? Most likely the documented alert lifetime: one month on Basic, two months on Essential and Plus, open-ended only on Premium and Ultimate. Second most likely is the ceiling of 15 triggers in three minutes, which stops the alert rather than throttling it.

The dashboard shows the signal but MT5 does nothing. Check the WebRequest allowlist first. It is the only failure here that produces total silence in both directions, because the EA never gets a response it could report on. Add https://api.nexumtrader.com under Tools, Options, Expert Advisors and restart the EA.

Does TradingView retry a failed webhook? For server-side failures, yes: a 5xx status other than 504 is resent after five seconds, up to three additional attempts. Since a slow endpoint can succeed on a later attempt after appearing to fail, retries are a duplicate-instruction risk worth understanding before building around them.

Why did only some of my accounts trade? Each account is evaluated independently against four checks: auto trade on, inside an active trading window, the symbol present in that broker's Market Watch under the exact payload name, and the EA online on a chart of that symbol. An account failing any check is skipped silently while the others still trade, so one misconfigured terminal cannot block the rest.

Can I test any of this outside market hours? Partly. A manual trade exercises the dashboard, the EA and the connection, and surfaces allowlist and auto-trading problems immediately. It cannot test the alert or the webhook, and orders sent into a closed market are declined regardless of how healthy the chain is.

Related reading

• Connect TradingView to MT5, the setup this article assumes you have.
• TradingView webhook alerts, the concepts behind the alert message.
• Troubleshooting and MT5 error codes, for the reference detail this article deliberately does not repeat.

This article describes the technical behaviour of TradingView alerts, webhook delivery and MetaTrader 5 order execution. It is not financial, investment or trading advice, and nothing in it is a recommendation to trade or to use any strategy. Third-party platform limits and pricing change; verify current terms with the provider before relying on them. Trading carries risk of loss.