Debug a TradingView Alert All the Way to Broker Fill

Write a case key before making changes: strategy version, alert name, source chart, destination account and symbol, side, quantity, and trigger time. Redact the private endpoint and credentials. This key keeps one event separate from nearby manual trades or retries. If copy trading is involved, debug the master through fill first, then add one row per follower because follower success is not atomic.

The runbook is intentionally linear. Pine cannot explain a broker rejection, and broker screens cannot prove which alert snapshot emitted. Changing several layers at once destroys causality. Preserve screenshots or exported text before recreating alerts, refreshing charts, editing mappings, or closing orders. Unknown is a valid temporary conclusion and should trigger reconciliation rather than a plausible guess.

If no event exists, stay in Pine. For an indicator, verify whether the selected `alertcondition()` or “Any alert() function call” path executed. For a strategy, determine whether the alert includes `alert()` calls, order fills, or both. A custom strategy order message requires `{{strategy.order.alert_message}}`. Check runtime errors and the documented burst halt of more than fifteen alerts in three minutes. Confirm that the condition occurred on a realtime bar rather than only in historical calculation.

If timing looks wrong, test repainting. Intrabar highs, lows, and closes can change before confirmation, and every-tick strategy calculations can differ from historical bars. Once-per-bar-close can align events with confirmed data but changes latency. Do not switch frequency casually during an incident. Capture the old configuration, reproduce in dry mode, approve the timing change, then recreate the server-side alert and assign a new version label.

Inspect the exact public HTTPS URL without exposing its private token. TradingView permits ports 80 and 443, does not support local or private destination addresses, and currently documents no IPv6 support. It sends `application/json` only when the final alert message is valid JSON; otherwise the request uses `text/plain`. A redirect to a sign-in page or a plain-text body reaching a JSON-only route can explain failure before any trade field is considered.

Timeout demands caution. The three-second limit describes sender waiting, not downstream side effects. Search receiving evidence for each attempt before retrying. TradingView's resubmission article documents three five-second resends only after qualifying 5xx responses and explicitly excludes 504. Do not generalize that behavior to DNS, TLS, connection, timeout, 3xx, or 4xx outcomes. If arrival remains unproven, preserve the ambiguity and continue with receiver and broker checks.

Do not validate the Pine source string alone. Placeholder replacement and dynamic concatenation can introduce invalid quotes, commas, or values. TradingView's content type reveals whether it recognized valid JSON, but parsing a captured safe sample gives more detail. Keep credentials and the full endpoint out of validators. If syntax passes, compare semantics: a Tradovate futures account and a TradeLocker CFD account can require different symbols even when the charts represent related markets.

HexTrade documents `dryRun: true` as validation without an order, so a successful dry record should have no broker order. It also documents `maxQty`, `allowedSymbols`, sessions, custom trade windows, cooldown, and an in-memory daily cap. A guardrail rejection can be correct. Preserve which field blocked the route instead of weakening several controls to make the test pass. Then rerun dry mode with the intended exact account.

A broker rejection should include a reason or category that directs the next check: authorization, unavailable contract, session, margin, account or firm limit, order semantics, or another destination rule. Do not keep editing JSON after the receiver selected the correct route and the broker returned a specific rejection. Resolve that account-facing cause through current broker or firm documentation. A marketable request can also remain absent if authorization expired even though previous tests worked.

Accepted and filled are separate. Limit and stop orders can work without filling, and partial fills create real exposure smaller than requested. Market orders can fill at prices different from the alert's chart value. Record state transitions until terminal or intentionally carried forward. If no matching order is found, check for wrong account and symbol before declaring loss. A nearby manual order is not automatically the webhook order.

A qualifying 5xx can produce four deliveries for one trigger. A Pine condition that remains true can produce several triggers. A receiver retry after lost broker acknowledgement can produce multiple submissions. A human can add another replay. Count all four layers separately. Use versioned strategy labels, account, symbol, side, quantity, and sender time to correlate, while recognizing that labels alone are not a documented idempotency guarantee.

In a copy group, one follower can fill while another rejects or remains unknown. Resending the source webhook is unsafe because the master and successful followers may already have exposure. HexTrade documents per-follower multipliers and group deactivation. Use those controls within an incident plan, inspect each broker account, and resolve exposure through authorized account actions. Do not promise atomic rollback across markets or platforms.