Your alert fires green on the chart, the log shows “sent,” and then nothing happens on your broker account. No error, no crash, just silence. If you’ve chased that ghost, the cause is almost never your strategy logic. I’ve debugged this exact complaint dozens of times while running automated order flow into Tradovate and Rithmic accounts. A tradingview webhook timeout is rarely about trading logic at all. It’s an infrastructure clock most traders never knew was running, and it kills more automated setups than bad code ever does.
Table of Contents
- Key Takeaways
- Why Does My TradingView Webhook Time Out?
- Why Won’t TradingView Send to My Custom Port?
- What Happens When Your Server Doesn’t Respond in Time?
- How Do I Fix TradingView Webhook Timeouts for My Automation?
- How PickMyTrade Avoids the Timeout and Port Problem for You
- Frequently Asked Questions
- Conclusion
Key Takeaways
- TradingView cancels any webhook request that doesn’t get a response within 3 seconds, no exceptions.
- Webhook URLs only work on ports 80 (HTTP) and 443 (HTTPS). Any other port is rejected before the alert even leaves TradingView.
- A 5xx server error triggers up to 3 automatic resends. A timeout or wrong port does not; the alert is simply gone.
- The fix is a two-step server: acknowledge in milliseconds, process the trade afterward.
- Most silent failures I’ve traced come from slow acknowledgment, not from a broken strategy.
Why Does My TradingView Webhook Time Out?
TradingView cancels a webhook request if your server doesn’t respond within 3 seconds of receiving it. That’s not a rough guideline, it’s a hard cutoff enforced on every single alert, on every plan tier, regardless of which exchange or symbol triggered it. The clock starts the instant TradingView sends the POST request, not when your code finishes running, so any delay before your first byte of response comes back counts against you. This applies before your trading logic ever gets a chance to run, which means a strategy that works perfectly can still lose orders if the server underneath it answers too slowly.
In the webhook failures I’ve triaged for traders moving from manual clicks to automation, slow acknowledgment is the single biggest cause, ahead of bad JSON, bad credentials, or broker rejections combined. Your server has to say “got it” almost instantly. Placing the actual trade can happen a moment later, but the first reply has to beat the clock.
The trap is that your automation often works fine in testing, when your server is idle and replies instantly, then starts silently dropping alerts once it’s also querying a broker API, checking risk limits, or writing to a database before it replies. Add 2 seconds of real work in front of your response, and you’re already past the line.
Why Won’t TradingView Send to My Custom Port?
TradingView webhook URLs only accept port 80 or port 443. Nothing else. If your endpoint is https://yourserver.com:8000/webhook or any address with a non-standard port typed into it, TradingView rejects the request outright before it ever reaches your network.
I’ve watched traders spend an entire weekend debugging “no orders firing,” convinced their strategy or their broker connection was broken, when the real issue was a :5000 sitting in the webhook URL from their local dev setup. The alert log shows it fired. It just never left TradingView’s side.
This rule surprises developers most, because running an app on port 3000, 5000, or 8000 is completely normal. TradingView doesn’t care what’s normal for you:
| Port setup | Works with TradingView webhooks? | What to do instead |
|---|---|---|
| Custom port (e.g. :8000, :5000) | No, rejected immediately | Put a reverse proxy in front on port 443 |
| Port 80 (HTTP) | Yes | Fine for testing, use 443 for anything live |
| Port 443 (HTTPS) | Yes | Standard choice for production endpoints |
| IPv6-only endpoint | No, not supported | Serve the webhook over an IPv4 address |
If your app runs on a non-standard port, the fix is a reverse proxy, nginx, Caddy, or your cloud provider’s load balancer, listening on 443 and forwarding internally to your actual process. TradingView only ever sees the 443 endpoint. Your app keeps its own port behind it.
A strict firewall or WAF can cause the same silent failure even on the right port. TradingView publishes the specific outbound IP addresses its webhook servers send from in its own documentation. If your infrastructure blocks unknown traffic by default, allowlist those IPs, or the request never reaches your app at all, and it’ll look identical to a timeout in your alert log.
What Happens When Your Server Doesn’t Respond in Time?
A timed-out webhook isn’t queued, retried, or logged for you to fix later. TradingView marks it delivered and moves on, even though your server never got the chance to act on it. That single behavior explains most “my alert fired but nothing happened” reports I see.
Retries do exist, but only for a specific case. If your server returns a 5xx error (500 to 599, except 504), TradingView resends the same alert up to 3 more times, 5 seconds apart, for a maximum of 4 attempts total. That’s the only scenario where a failed webhook gets a second chance. A timeout or a non-2xx response from a slow endpoint doesn’t get that courtesy, and neither does a request rejected for using the wrong port. Both are treated as delivered and discarded the moment they fail, with nothing queued on TradingView’s side for you to retrieve later. Whatever state your server was in at that exact moment is the only chance that alert gets.
Here’s the part that trips people up: the fact that a 5xx error gets retried and a timeout doesn’t creates a strange incentive. If your endpoint is going to fail, it’s actually safer for it to crash loudly with a 500 than to hang silently past 3 seconds. A crash gets a second chance. A hang gets none.
How Do I Fix TradingView Webhook Timeouts for My Automation?
The fix is to separate acknowledging the alert from acting on it. Reply with an HTTP 200 the instant your server receives the payload, before you touch a broker API, a database, or a risk check. Do the actual order logic after you’ve already answered TradingView.
Run through this checklist on your webhook receiver:
- Return a 200 response within a few hundred milliseconds of receiving the POST, before any broker or database call.
- Move the actual trade execution into a background task, queue, or async handler that runs after the acknowledgment.
- Serve your webhook endpoint on port 443 (or 80 for testing), using a reverse proxy if your app runs on a custom port internally.
- Confirm your endpoint is reachable over IPv4; TradingView does not support IPv6 webhook destinations.
- Enable two-factor authentication on your TradingView account. Webhook alerts require it before they’ll send at all.
- If a call to your broker’s API is slow, don’t make TradingView wait for it. Acknowledge first, then place the order.
- Keep your alert message under TradingView’s size limits, 4,000 characters in the Message field or 40,960 in Pine Script’s
alert(), since an oversized payload adds parsing overhead your server doesn’t need.
Every one of these is a one-time setup fix. Once your server replies fast and lives on the right port, the timeout problem doesn’t come back. It’s not a strategy issue you’ll keep chasing, it’s plumbing you fix once.
How PickMyTrade Avoids the Timeout and Port Problem for You
This is exactly the layer PickMyTrade exists to remove. Instead of standing up your own server, opening ports, and writing the ack-then-process logic yourself, your TradingView alert points at PickMyTrade’s endpoint, which already acknowledges within milliseconds and routes the order to Tradovate, Rithmic, or your prop-firm account in the background. If you haven’t wired up that connection yet, our Tradovate automation setup guide walks through it end to end.
Tired of debugging server response times instead of trading? PickMyTrade receives your TradingView webhook instantly, on the right port, every time, then forwards your order with sub-200ms latency. Start automating for $50/month and stop losing alerts to a clock you didn’t know existed.
Frequently Asked Questions
TradingView cancels a webhook request if the receiving server doesn’t respond within 3 seconds. That 3-second window starts the moment TradingView sends the request, and it applies to every webhook alert regardless of plan or account type.
TradingView only delivers webhooks to port 80 or port 443. Any other port number in the URL, including common development ports like 3000, 5000, or 8000, is rejected before the request leaves TradingView. Use a reverse proxy on 443 if your app runs elsewhere internally.
No. A timeout is treated as delivered and discarded, with no resend. Retries only happen for 5xx server errors (excluding 504), which get resent up to 3 additional times, 5 seconds apart, for a maximum of 4 total attempts.
Respond with an HTTP 200 immediately after receiving the alert, before running any trade logic. Move broker API calls, database writes, and risk checks into a background process that runs after you’ve already acknowledged the request. That reordering fixes most timeout cases.
Yes. PickMyTrade’s endpoint runs on the correct port and acknowledges TradingView’s webhook instantly, then handles the broker order routing separately with sub-200ms latency, so your alert never sits waiting past the 3-second cutoff.
Conclusion
A tradingview webhook timeout almost always traces back to one of two rules: the 3-second response clock, or the ports 80/443 restriction. Neither has anything to do with your trading strategy.
- 3-second timeout: your server must acknowledge fast, before doing any real work.
- Ports 80/443 only: custom ports get rejected outright; front them with a reverse proxy.
- No retry on timeout: unlike a 5xx error, a slow response doesn’t get a second chance.
- Fix it once: reorder your response logic and lock down your port, and the problem stops recurring.
Get the plumbing right, and your alerts stop disappearing into silence. For the next layer of reliability, see our guide to troubleshooting TradingView alert issues and our walkthrough of setting up webhook alerts with custom tools.
Disclaimer:
This content is for informational purposes only and does not constitute financial, investment, or trading advice. Trading and investing in financial markets involve risk, and it is possible to lose some or all of your capital. Always perform your own research and consult with a licensed financial advisor before making any trading decisions. The mention of any proprietary trading firms, brokers, does not constitute an endorsement or partnership. Ensure you understand all terms, conditions, and compliance requirements of the firms and platforms you use.
Also Checkout: Automate TradingView Indicators with Tradovate Using PickMyTrade
