TLDR: TradingView cancels a webhook request when the receiving server takes longer than three seconds to respond. A timeout can come from server load, network delay, slow application code, synchronous broker API calls, database work, or a downstream service that never returns. The dangerous part is uncertainty: the receiver may have started processing the request even though TradingView reports a timeout. Do not blindly resend a live-trading message. Check the Alert log, receiver logs, and broker orders first. If the timeout-prone webhook chain is unnecessary for your setup, Ultra Mega Trader can automate supported TradingView broker workflows without webhook delivery or an external server.
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
What Does a TradingView Webhook Timeout Mean?
A “request took too long” or “timeout exceeded” message means TradingView did not receive an acceptable response from the webhook endpoint within three seconds.
It does not automatically mean:
- The alert failed to trigger.
- The request never reached the server.
- The server did not begin processing it.
- The broker did not receive an order.
That uncertainty is why timeout troubleshooting must start with logs rather than another live test.
Common Causes of TradingView Webhook Timeouts
1. Waiting for the Broker Before Responding
A receiver may validate the signal, call the broker API, wait for an order response, store the result, and only then return an HTTP response to TradingView. Any slow downstream step can exceed three seconds.
2. Server Cold Starts
Serverless functions and sleeping applications may need time to start before processing the request. That delay can consume most of TradingView's response window.
3. Overloaded or Underpowered Hosting
CPU limits, memory pressure, too many simultaneous signals, or an exhausted connection pool can delay the response.
4. Slow DNS, TLS, or Network Routing
TradingView must resolve the domain, establish a connection, negotiate security, send the request, and receive a response. Problems in that path can cause a timeout before application processing finishes.
5. Database or Logging Delays
Waiting for a database transaction, remote log service, spreadsheet, or notification system can turn a quick acknowledgement into a slow request.
6. Receiving-Service Outage
The service may accept a connection but fail to complete the request because an internal dependency is unavailable.
How to Diagnose the Timeout Safely
- Record the exact TradingView alert timestamp and message.
- Check the Alert log and Webhook status.
- Search the receiver's access log for the same timestamp.
- Search the application log for the signal ID, symbol, and action.
- Check the broker's order log for accepted, rejected, working, cancelled, or filled orders.
- Reconcile positions before testing again.
| Evidence | Interpretation |
|---|---|
| No inbound request in receiver logs | The timeout occurred before the application received the message |
| Inbound request, no completed application log | The application stalled or crashed while processing |
| Application created an order but TradingView timed out | Do not resend until the broker position is reconciled |
| Receiver returned quickly but TradingView still reports failure | Inspect proxy, TLS, response format, and network path |
How Developers Usually Prevent the Three-Second Timeout
A robust webhook receiver often separates receipt from longer processing:
- Authenticate and minimally validate the request.
- Assign a unique message or idempotency key.
- Store the instruction in a durable queue.
- Return a successful response quickly.
- Process the broker order in a separate worker.
- Reconcile the final broker response and position.
This architecture can prevent the TradingView request from waiting on the broker. It also introduces a queue, worker, database, duplicate-protection logic, monitoring, and recovery procedures. Returning success before the broker order exists means the Webhook status is no longer proof of execution.
Webhook Retries and Duplicate-Order Risk
TradingView currently documents resubmission for HTTP 500–599 responses except 504, with up to three resends after the original request. Timeout behavior and receiver behavior must be evaluated carefully.
A trading receiver should treat repeated delivery of the same instruction as a possibility. Use a unique event identifier and verify whether the order already exists before placing another one.
Never solve an ambiguous timeout by repeatedly clicking “test” against a live account.
When the Receiver Says It Worked but TradingView Says Timeout
Both can be true. The receiver may complete its work after TradingView's three-second window has already expired. This is why a timeout is not the same as a confirmed failure.
The source of truth is the broker's accepted orders and positions, combined with the receiver's unique-event logs. If those systems cannot reconcile one signal to one order, the automation stack needs more than a faster server.
A No-Webhook Alternative to Timeout Troubleshooting
Ultra Mega Trader Automator works in the browser with TradingView strategy activity and the broker connection opened inside TradingView. It does not send an HTTP webhook to an external receiver, so TradingView's three-second webhook response limit is not part of the UMT workflow.
UMT also removes JSON commands, a separate webhook server, custom middleware, and separate broker API keys. It still depends on an open browser, stable internet, TradingView availability, a correctly configured strategy, and a supported broker connection.
See the broader comparison in TradingView Webhook Alternatives.
Ready to test automation without webhook timeouts? Start a free seven-day UMT trial by contacting support@ultramegatrader.com. Use paper trading first.
TradingView Webhook Timeout FAQ
How long does TradingView wait for a webhook response?
TradingView currently states that a request is cancelled if the remote server takes longer than three seconds to process it.
Did a timed-out webhook still place my trade?
Possibly. The server may have continued processing after TradingView stopped waiting. Check receiver logs and broker orders before resending.
Should my webhook wait for the broker order response?
Waiting can exceed the three-second limit. Production systems often acknowledge receipt quickly and process separately, but that requires durable queues, duplicate protection, monitoring, and reconciliation.
Does UMT have the TradingView webhook timeout?
No webhook is sent in UMT's browser-based workflow, so the webhook response limit does not apply. Other browser, network, TradingView, broker, and market risks remain.
Sources
- TradingView: Configure Webhook Alerts
- TradingView: Webhook Error Meanings
- TradingView: Webhook Resubmission
Educational content only. Automated trading involves risk of loss. A webhook acknowledgement, timeout, or retry does not prove whether a broker accepted or filled an order. Test with paper trading and reconcile positions before resending signals.
