TradingView Webhook Not Executing in MT5? Delivered but No Trade

When a TradingView webhook is delivered but not executing in MT5, the successful status in TradingView's log only proves that the receiving service answered within three seconds, and it says nothing about the trade itself. Between that answer and an order in MT5, the alert still has to pass the receiver's own checks, reach a running terminal and be accepted by the broker, and any of those steps can stop it without TradingView ever finding out.

So when TradingView shows the alert as delivered and MT5 shows nothing, stop looking at TradingView. The answer is in the receiver's log, the EA's log or the broker's response. This guide walks through each of them in that order, using PineHook's Signal Logs as the example.

Why "delivered" does not mean "executed"#

Most TradingView-to-MT5 services, PineHook included, answer the webhook as soon as they have checked the message and queued it for the terminal. Executing the order takes longer. The message has to travel to the EA, and the broker has to respond. If the receiver waited for the broker before answering, a slow fill would push it past TradingView's three-second limit, and the alert would be marked as failed even though it traded.

As a result, "delivered" and "executed" are recorded in different places: TradingView's alert log holds the first, while the receiver's log and the Experts tab in MT5 hold the second.

Step 1: find the alert in the receiver's log#

Open Dashboard → Signal Logs and find the row for the alert's time. If there is no row at all, the message probably carried a license key PineHook could not match to an account, or it was an exact repeat of an alert from the previous 12 seconds, which PineHook drops as a duplicate without creating a row. Giving each new alert a unique id= ensures a genuine second alert is never mistaken for a repeat.

If the row is there, its status badge tells you how far the alert got before it stopped:

Step 2: check whether a setting blocked the alert#

This is the case that surprises people most. The request behind a blocked alert is itself valid, so PineHook answers it with HTTP 200 and TradingView shows it as delivered, while the Signal Logs row explains which setting stopped it. The settings traders run into most often are these:

• Signal Authentication is on and the alert has no auth= value, or the wrong one,
• the symbol is excluded by a symbol filter, or was switched off with eaoff, which eaon reverses,
• the alert arrived outside your Active Hours,
• the News Filter window was open,
• a drawdown guard or position limit refused a new entry.

Each of these is a safeguard doing what you asked it to do, so the fix is either to correct the alert or to change the setting on purpose. The full list of block reasons and their exact wording is in Alert error messages.

Step 3: check whether the EA received the alert#

An alert that stays at RECV, or that appears under Queued Alerts, is waiting for an EA that is not connected, usually because the terminal is closed, the computer or VPS restarted, or the EA was removed from its chart. PineHook keeps the alert in the delivery queue, but whether it runs after reconnection depends on your missed-alert recovery setting, and entries are deliberately never replayed late. Our guide to what happens when the MT5 EA disconnects explains why and how to set it up.

While you are there, check that the EA on that terminal uses the license key from the alert. Two accounts on two licenses look identical from TradingView's side, and an alert sent to the wrong key will trade on the other account.

Step 4: read why the broker or EA refused the trade#

A FAIL row carries the reason the trade did not happen, and this table maps the common messages to their causes and to the guide that fixes each one:

The same detail also appears in MT5 under View → Toolbox → Experts, together with anything the terminal itself printed.

Step 5: check whether it traded somewhere you did not look#

An EXEC row with no visible position usually has a simple explanation: the trade went to a different account or terminal, it already closed at its stop or target, or the alert was a close that found nothing to close. A close with no matching position is not an error, so PineHook records it as executed with nothing closed, and comparing the symbol, magic number and direction against your open positions and history will show which of these it was.

How PineHook makes "no trade" easy to explain#

With most bridges, an alert that was delivered but never traded leaves you comparing three logs and guessing at a numeric code. PineHook was built so that every alert ends in one place with one readable answer. The Signal Logs row says whether the alert executed, which of your own settings blocked it, or what the broker objected to, in words such as SL distance 0.00008 is below broker minimum 0.00015 or with the broker's description printed beside its code. When one of PineHook's own checks refuses an entry, such as your spread limit, the row also shows the value it observed and the limit you set, so you can see at a glance whether to change the alert or the setting.

Before you go live, Signal Logs → Test EA Connection sends a test through the live route without placing a trade, and on MT5, it reports whether AutoTrading, EA trading and the account's trading permission are all switched on. If you are still debugging delivered alerts by hand, create a PineHook account without payment details and see the difference on a demo account.

FAQ#

Why doesn't PineHook return an error to TradingView when a trade fails?

The trade fails after TradingView's three-second window has closed, so there is no open request left to answer. PineHook records the result on the Signal Logs row instead, where the broker's message and PineHook's explanation are both available.

Should I resend a TradingView alert by hand after a failed trade?

Only after you have read the reason and checked the broker's history. A failure on PineHook's side is usually safe to repeat once fixed, but an UNKNOWN outcome means the order may have reached the broker, and resending it could double the position.

Why does TradingView show the webhook as sent when no trade opened?

TradingView only records whether the receiving service answered the request. Whether the trade then executed is decided later by the EA and the broker, so the explanation lives in the receiver's log rather than in TradingView.

Related guides#

• TradingView webhook not working
• MT5 EA not trading
• Signal Logs reference
• Trade errors

MetaTrader and TradingView are trademarks of their owners, and PineHook is an independent product that is not affiliated with, endorsed by, or sponsored by MetaQuotes or TradingView. Leveraged trading carries a high risk of loss, so test any automated setup on a demo account before you trade it live.