TradingView Webhook Not Working: Diagnose Every Error Boundary

A chart marker is not proof that a running alert emitted, and an alert event is not proof that a webhook arrived. Likewise, a successful HTTP response may mean accepted for processing rather than broker-filled. Build a timeline from evidence owned by each system. Record the chart symbol and timeframe, alert name and creation version, trigger time, Webhook status, sanitized payload, receiver result, connected account, and broker state. The first missing or contradictory artifact identifies the narrowest useful investigation.

This method prevents common category errors. Rewriting JSON cannot fix an expired alert. Recreating an alert cannot fix an incorrect `accountId`. Retrying a valid request cannot fix an unavailable contract or an account restriction. Most importantly, a sender timeout cannot safely be treated as no order. Pause automation and reconcile downstream state whenever delivery or submission might have occurred but final evidence is missing.

Open the alert manager and log before touching the webhook body. If there is no event, test whether the condition actually became true in realtime and whether the selected trigger matches the code. `alertcondition()` creates selectable triggers only for indicators; it has no alert-trigger effect in strategies. `alert()` requires its guarded code path to execute and its frequency to permit emission. Strategy order-fill events require the alert dialog to include order fills, and a custom `alert_message` requires the corresponding placeholder.

Frequency and repainting explain many timing disputes. Fluid values can satisfy a condition during an open realtime bar and no longer satisfy it after refresh. Once-per-bar-close improves confirmation at the cost of waiting for the bar. TradingView also documents that if more than fifteen alerts occur within three minutes, further alerts are halted. Treat a burst as a script-state problem to correct, not as a reason to create more duplicate alerts.

For 3xx, correct the alert URL rather than relying on a redirect to another path or login page. For 4xx, inspect endpoint existence, authentication, content type, body format, required fields, and any rate limit. For 5xx, inspect service health and processing errors. TradingView resends only qualifying 500–599 responses other than 504, after five seconds, for up to four total deliveries. Your investigation must therefore anticipate duplicates whenever that rule was entered.

A timeout is especially ambiguous. TradingView cancels a request when the remote server takes longer than three seconds, but that fact alone does not say whether downstream work began. DNS or connection failures may prevent arrival; slow application processing may occur after arrival. Compare receiver access and application records before manual action. If the URL resolves to a local or private address, uses an unsupported port, or has broken TLS, fix the public endpoint rather than changing trading fields.

TradingView sends `application/json` only when the complete message is valid JSON. Dynamic Pine strings can fail because of missing quotes, trailing commas, raw line breaks, unescaped labels, or invalid numeric text. Placeholders can also be quoted inconsistently. Parsing a copied rendered sample exposes syntax before it reaches a trading route. Never paste the private webhook URL, broker credentials, or account secrets into a public validator or support message; sanitize the body and retain only fields required to reproduce formatting.

Once syntax passes, validate semantics. HexTrade's troubleshooting docs identify inactive alerts, invalid JSON, wrong lowercase platform slug, account mismatch, and symbol mismatch as common causes. A futures account might expect `NQ`, while a CFD account might expect `NAS100`. The chart symbol and payload symbol can differ, and `symbolOverride` is documented for that purpose. Change one field at a time and preserve each dry-run response so the corrected boundary is obvious.

HexTrade's troubleshooting documentation points to balance, limits, and session hours as common broker-rejection areas. Those categories are starting points, not proof of a specific cause. Read the actual broker-facing result and compare it with the connected account. Futures contracts expire and roll, so a symbol that worked previously can become unavailable or map differently. A chart on a continuous contract does not guarantee that the destination accepts the same identifier at that moment.

An accepted marketable order can still fill at an unexpected price, while a limit or stop order can remain working or never fill. Partial execution is also different from rejection. Your incident record should preserve requested versus accepted quantity, order type if supported, broker identifier if available, and final status. If the status is unknown, freeze retries and inspect the destination account directly. The cost of waiting for evidence is usually lower than an accidental second futures position.

Start a simple incident note before changing anything. Screenshots taken after an alert is recreated can erase the original context, and chart refreshes can alter repainting evidence. Record the alert's creation version and current snapshot assumptions. If TradingView shows no event, stay in the Pine and alert layer. If it shows a transport error, stay in URL, request, or receiver health. If HexTrade validates but a broker rejects, stop changing JSON syntax and inspect the account-facing reason.

When the immediate issue is fixed, add a prevention control. That may be a payload parser test, `allowedSymbols`, `maxQty`, a clear `strategyName`, a bar-close rule, a route checklist, or a credential-redaction rule. Recreate the alert if its script, input, chart, or message snapshot changed. Then perform one controlled test and monitor the first live fills. Do not use a successful later order to assume an earlier unknown attempt vanished; reconcile both separately.