Researcher traces a chart notification through receiver validation to an illustrative broker rejection, using an incident checklist.
Conceptual execution-chain troubleshooting scene. The displayed interface and example event times are illustrative, not actual order records.

Trading technology

TradingView alert fired, but no trade executed: where to look first

A TradingView alert is a notification, not proof that a broker accepted an order. An automated setup may involve a TradingView strategy, a live alert, an HTTPS webhook, a server or execution provider, a brokerage API and the broker's risk checks. Each stage can succeed while the next one fails.

By Atlas Liaison Group · Sources checked November 2, 2026 · Documentation research

The fastest way to diagnose a missed order is to find the last stage that you can prove succeeded. Don't change the strategy, recreate every alert or disable risk limits until you know where the chain broke.

Trace a TradingView alert from notification to broker order

StopWhat to verifyWhat the result tells you
1. Chart/strategyWas there a confirmed live event on the correct symbol and timeframe?A backtest arrow alone does not establish a live alert.
2. TradingView alertDoes the Alerts Log show the alert triggered at that time?Confirms the configured server-side alert ran.
3. Webhook deliveryWhat does the Alerts Log's webhook status show?Separates send/delivery failures from later execution problems.
4. Receiver/bridgeDid the endpoint log receipt, validate the payload and attempt an order?Isolates data, authentication and server processing failures.
5. Broker responseWas the order accepted, rejected, cancelled or never submitted?Distinguishes routing from buying-power, instrument and order-rule issues.

1. Verify the alert actually belongs to the strategy you are inspecting

TradingView creates a server-side copy of a strategy when you create its alert. Later chart changes do not rewrite that running alert. If you changed settings, symbols, timeframe, strategy logic or message templates on the chart, the old alert may still be using the earlier snapshot. Compare the live alert's settings to your saved build and record when it was created. Recreate the alert deliberately only after you have verified the replacement, rather than disturbing a working configuration during diagnosis.

A strategy can also calculate a condition on a bar close yet simulate the order filling on the next bar by default. This explains some apparent one-candle differences; it is not, by itself, evidence of missing webhook delivery.

2. Read TradingView's webhook status, not just its alert notification

Open the Alerts Log and inspect the alert's webhook-status information. Common failure classes include:

  • 3xx: the receiver is redirecting the request, perhaps to a changed endpoint or login page.
  • 4xx: incorrect endpoint, rejected authorization, invalid JSON or request limits.
  • 5xx: an internal server error or downstream processing failure.
  • Timeout: the receiver did not respond fast enough. TradingView cancels webhook requests when a receiver takes more than three seconds.
  • Invalid URL / TLS issues: domain, HTTPS or connection problems.

TradingView webhooks send a POST request to the configured endpoint. If the alert message parses as JSON, TradingView marks its content type as application/json; otherwise it sends plain text. A receiving application that expects JSON can reject a plain-text payload.

3. Check the receiver without exposing credentials

If delivery is shown as successful, inspect the bridge or broker-integration logs for the same event timestamp. Look for the incoming alert ID or a safe correlation ID, the symbol as the broker expects it, order side, instrument availability and the broker API response. A received webhook does not mean the order was placed; the bridge might have rejected it before sending anything onward.

Never put passwords, account tokens or API secrets directly in webhook messages, public logs or screenshots. Use authenticated endpoints and secret storage.

4. Check broker-specific rejection reasons

When a broker receives an order, it can reject it because of instrument naming, market status, margin, trade size, stale positions, unsupported order types or account rules. Read the broker's actual error response. Don't infer the cause from a green TradingView notification alone.

If the account is live, perform troubleshooting in a safe test environment or with non-executing diagnostic requests whenever possible. Avoid replaying live order webhooks blindly: doing so can create duplicate positions.

A compact incident record to keep

For every missed trade, record: event date/time with timezone; strategy build and alert creation date; symbol and timeframe; alert event ID; webhook status; bridge receipt/status; broker order ID or rejection; and whether the issue recurred. A ten-line incident record can be more useful than 100 screenshots when the failure is intermittent.

Want to configure TradingView alerts?

Explore TradingView. Affiliate disclosure: Atlas may earn a commission if you subscribe through this link, at no additional cost to you. Subscription does not guarantee broker compatibility or trading results.

Related Atlas resources: TGIM trading technology · Quant Engineering · Affiliate disclosure

Sources and further reading

More tools for the work behind your business →