TradingView Alert Troubleshooting and Execution

Find the Last Confirmed Event

Start with one failed trade, not the account's entire history. Collect the chart symbol and timeframe, alert condition, actual message, receiver timestamp and broker result. Use the same timezone and preserve the original timestamps.

This sequence avoids a common waste of time: changing strategy logic after the receiver has already logged the correct instruction. Once that record exists, follow the next stage.

No Alert, No Webhook or No Order

A historical strategy trade is not proof of a realtime alert. Check when the running alert was created, which script snapshot it uses and which event types were selected. The Pine guide explains those distinctions.

For delivery, TradingView documents a three-second response timeout and a Webhook status column. Read that status alongside receiver logs. A timeout does not, by itself, establish whether the application already began processing the request. ^[S02]

For execution, retain the original broker or exchange error. “Order failed” is insufficient to distinguish an invalid quantity from a closed market or expired authentication. A rejected stop and an accepted entry need separate handling; do not mark the whole trade successful from the entry alone.

Duplicate Signals and Delivery Retries

Compare the earliest records first. Two different alert events indicate a source-side question. One event appearing twice at the receiver indicates delivery or forwarding. One receiver event producing two submissions points further downstream.

TradingView documents up to three resends after certain HTTP server errors, five seconds apart. The webhook guide gives the exact scope. Broker-order retries are a separate policy owned by the execution route. ^[S03]

A useful duplicate identity must distinguish a legitimate second action from a repeated delivery of the first. Timestamp and symbol alone may not be enough: a strategy can emit multiple valid events on the same instrument at the same time.

Avoid blindly replaying a timed-out live instruction. First query the account and look for a matching order. A missing acknowledgement does not prove a missing trade.

Measure Alert-to-Fill Latency

Signal time

Define the beginning precisely: the script event, a bar close or the alert generation timestamp. Those moments are not necessarily interchangeable.

Receiver time

Record when the receiver first accepted the HTTP request. Comparing this with the alert timestamp estimates the earlier part of the route only when the clocks are aligned.

Submission time

Record the execution service's submission and the broker acknowledgement separately. A queue or reconnect can delay submission after successful webhook delivery.

Fill time

Use the broker's actual fill timestamp. A limit order can remain accepted and unfilled for reasons unrelated to network speed.

The following timeline is an invented diagnostic example, not a benchmark or service measurement.

In this example, most elapsed time lies before receiver arrival. Optimizing the 50-millisecond processing interval would not remove the 2.4-second earlier interval. Clock error can invalidate that conclusion, so record clock synchronization and timestamp precision.

For a real comparison, collect multiple observations under stated market conditions and report the median, upper percentiles and failures. A single fastest trade is not a useful promise about future execution.

Rejected Orders, Missing Stops and State Mismatches

Compare requested and accepted quantity, not just the action. Minimum order size, quantity steps and product-specific units belong in the crypto and MetaTrader checks.

A position can also differ from the strategy after a manual close, rejected entry or partial fill. Establish the actual account state before resuming or replaying instructions. Check outstanding orders as well as positions: a flat position does not prevent a working order from opening exposure later.

For futures, retain the dated execution contract. A valid chart symbol can still target an old or unsupported expiry. For stocks, record the session and time-in-force of the submitted order.

Questions and Answers

Why does delivered not mean filled?

Delivery concerns the receiver's HTTP request. The receiver still has to interpret the message and submit an eligible order, and the venue must execute it.

How do I locate the source of a delay?

Match alert, reception, submission, acknowledgement and fill timestamps. Compare adjacent intervals using aligned clocks.

Can a retry create a duplicate trade?

Yes, when the original action succeeded and a repeated instruction is executed again without appropriate duplicate handling. Verify actual account state before a manual replay.

What should I send to support?

One event's timestamps, redacted final payload, route and account environment, receiver response, broker order ID and exact error. Remove secrets while preserving the fields needed to trace the incident.