TLDR: If a TradingView webhook seems unreliable, separate alert generation, notification permission, HTTP delivery, receiver acceptance, queue processing, broker submission, and fill. Give every event a unique identifier, compare TradingView's Alert log with receiver and broker records, acknowledge durably accepted requests within three seconds, handle documented resends without creating duplicate orders, and reconcile uncertain outcomes before retrying.
Stop Executing Trades By Hand.
UMT Automator turns your TradingView or NinjaTrader strategy into automatic, hands-free execution — no code, no webhooks, no missed signals. Prefer a ready-made edge? Browse UMT's tested Strategies & Indicators built for both platforms.
Free 7-day trial on the Automator · No credit card required
“It works sometimes” is a symptom, not a diagnosis. One event may never have triggered in TradingView. Another may have been muted by a notification schedule. A third may have reached the endpoint twice after a server error. A fourth may have been accepted by the receiver but rejected by the broker.
Measure Every Handoff
Check the exact expected time in TradingView's Alerts Log, then correlate the event through the receiver, queue, worker, broker, and market. No alert-log entry points to the strategy, symbol, timeframe, frequency, expiration, or stopped-alert state. An alert with failed Webhook status points to URL, network, TLS, payload, authorization, or receiver behavior. A successful webhook with no order is a downstream problem.
- Strategy or condition occurred on a realtime bar.
- Alert appears in the log.
- Webhook action was enabled and permitted by its schedule.
- HTTP delivery completed.
- Receiver durably accepted the event.
- Queue worker processed it once.
- Broker accepted or rejected the order.
- Market filled, canceled, or left the order open.
For status-specific troubleshooting, see TradingView Webhook Status Failed and TradingView Webhook Not Working.
Rule Out Alert Configuration Problems
Running alerts use saved context
TradingView saves a server-side copy of a script alert's inputs, symbol, and timeframe. Later chart or input changes do not update that alert. Recreate it after changing strategy settings and verify the message and destination.
Frequency and schedules change delivery
Pine alerts operate on realtime bars. “Once per bar close” waits for confirmed data; intrabar modes can react earlier but may change behavior. TradingView also stops a script alert after more than 15 triggers within three minutes. Notification schedules can record a trigger while blocking outbound webhooks outside the active window; use 24/7 for continuous automation. Webhook URLs are not saved in alert presets, so verify the URL in every active alert.
Respect the Webhook Contract
TradingView accepts destination ports 80 and 443, currently does not support IPv6 webhook delivery, and cancels a request when the receiver takes longer than three seconds to respond. Valid JSON receives an application/json content type; other messages use text/plain. Webhook alerts require two-factor authentication. Use a public final HTTPS endpoint, valid DNS and TLS, the correct POST route, and an authenticated receiver.
The receiver should authenticate, validate required fields and risk limits, create an idempotency record, durably store or queue the event, and return a response. Do not wait for a broker fill, slow database work, or notifications before responding. Do not return success before durable acceptance.
Handle Retries Without Duplicate Orders
TradingView documents a resend after five seconds for HTTP 500–599 responses except 504, with up to three resends after the original attempt. One trigger can therefore produce four sends. Store a stable event identifier and processing state before broker submission. Reuse a client-order identifier when supported, and return the known state when the same event arrives again.
A timeout creates uncertainty: the receiver may have sent an order even though the response was lost. Search receiver, queue, and broker records by event ID, time, symbol, and account before manually repeating a live action.
Monitor Reliability With Evidence
- Expected events versus Alert-log entries.
- Alert-log entries versus webhook successes and failures.
- Receiver arrivals versus durably accepted events.
- Queue age, worker failures, and dead-letter volume.
- Duplicate deliveries detected and duplicate actions prevented.
- Broker submissions, acknowledgements, rejections, and unknown outcomes.
- Latency reported by stage rather than one blended number.
Use synchronized UTC timestamps and sanitized correlation data. TradingView's official status page is useful when unrelated alerts and endpoints fail together, but it cannot prove that one specific delivery succeeded.
Test Without Risking Live Capital
- Use a non-ordering endpoint or paper account.
- Create one controlled alert with a unique non-sensitive event ID.
- Verify symbol, timeframe, inputs, frequency, expiration, schedule, message, and URL.
- Trace the ID through TradingView, the receiver, queue, and paper broker.
- Change one variable at a time.
When a No-Webhook Workflow Is Simpler
UMT Automator removes the user-managed webhook, JSON, hosted receiver, and separate broker API-key layers for eligible TradingView strategies through a browser-based workflow. It does not guarantee alert generation, connectivity, order acceptance, fills, synchronization, profitability, or zero downtime.
Review the current UMT Automator setup requirements, then request the free 7-day trial and evaluate the workflow in paper trading.
Frequently Asked Questions
Why does my TradingView webhook work only sometimes?
The inconsistent stage may be the alert, schedule, HTTP delivery, receiver, queue, broker submission, or fill. Compare all records for the same event.
Does TradingView guarantee webhook delivery?
No. TradingView notes that webhooks may occasionally fail to reach the specified URL. Build monitoring and recovery around that possibility.
Can a webhook succeed while the trade fails?
Yes. HTTP success confirms the receiver's response, not payload validation, broker acceptance, or a fill.
Risk disclaimer: Automated trading involves substantial risk. Test alerts, retries, duplicate protection, symbol mapping, position handling, and recovery procedures in simulation or paper trading. Reliable message handling does not guarantee order acceptance, fills, execution price, synchronization, profitability, or protection from losses.
