TradingView Webhook Not Working: Timeout, Ports, Retries

The alert fired. You can see it in the log, timestamped, with the right message. Your server shows nothing, or your bot placed the order twice, and now you're staring at two systems that each swear they did their job. Both are usually telli

The alert fired. You can see it in the log, timestamped, with the right message. Your server shows nothing, or your bot placed the order twice, and now you're staring at two systems that each swear they did their job.

Both are usually telling the truth. A webhook (an automatic HTTP request TradingView sends to a URL you choose whenever an alert triggers) is a short, strict conversation with hard limits, and the failures live in the fine print. Most dead TradingView webhooks come from five documented limits, and the one that surprises people is the retry rule that can fire the same alert up to four times.

Read the Webhook status column before you touch anything

Don't start by rewriting your server. Open the alert log and look at the "Webhook status" column. TradingView's own page on how to configure webhook alerts says webhooks may occasionally fail to reach the URL and points you to that column to monitor delivery.

That column splits your problem in half. If the log shows no webhook attempt at all, the issue is on the TradingView side (the alert, the account, the URL field). If it shows an error, TradingView reached out and something on the receiving end said no.

Most debugging time goes to the wrong half, so spend the thirty seconds.

Five hard limits decide whether the request ever lands

The same support page lists the rules, and each one has bitten somebody:

• 2FA must be on. Webhook alerts are only allowed when two-factor authentication is enabled on your account.
• Only ports 80 and 443. If your URL carries a port number, any other port is rejected. A dev server on port 3000 or 8080 will never receive a thing.
• Three seconds to answer. If the remote server takes longer than three seconds to process the request, TradingView cancels it.
• No IPv6. The page states IPv6 isn't currently supported for webhooks, so an endpoint that only resolves over IPv6 is unreachable.
• Fixed sending addresses. Requests come from four IP addresses, listed on the page, which matters if your host has a firewall or allowlist.

Running through those five against your setup finds the culprit more often than any clever theory does.

The three-second clock punishes servers that do the work before replying

Here's the pattern that trips automation builders. Your endpoint receives the webhook, calls a broker API to place the order, waits for the broker to answer, and only then responds to TradingView. If the broker is slow that day, you blow past three seconds, and TradingView marks the delivery as timed out while your order may still be in flight.

TradingView's page on what webhook errors mean lists "timeout exceeded" separately and ties it to overloaded servers or network problems. The fix is architectural, and this part is my opinion rather than anything TradingView prescribes: acknowledge fast, work later. Reply with a 200 the moment you've validated and queued the message, and let a separate process talk to the broker.

Think of it like a restaurant host. The host's job at the door is to say "you're on the list," not to cook your dinner while you stand there.

A 5xx reply can make TradingView send the same alert again

This one deserves its own section because it costs real money. TradingView's webhook resubmission page says that if the receiving application returns an HTTP status code between 500 and 599, except 504, the notification is sent again after 5 seconds, with a total of 3 resends possible.

Do the arithmetic. One alert, one initial send, three resends: up to four deliveries. If your server crashes after placing the order but before returning a clean 200, you can get the order placed, the error returned, and the same message arriving again five seconds later.

The docs don't say what happens after a timeout, so don't assume either direction. Design as if a request might arrive zero, one, or several times, and make the receiver safe in all three cases.

Invalid JSON turns into plain text, and strict servers reject it

TradingView decides the content-type header from your message. Per the configuration page, valid JSON goes out as application/json and anything else goes out as text/plain. A receiver that insists on JSON can return a 4xx error for the second kind, and TradingView's errors page lists invalid JSON among the causes of client errors.

The classic way to break your own JSON is a placeholder. A placeholder is a {{curly brace}} tag that TradingView swaps for a live value when the alert fires. Numbers drop in cleanly, but a string like a ticker needs its own quotes, or the substituted message stops being valid JSON. That's my reading of how substitution plus JSON syntax interact, so test it: paste the rendered message into a JSON validator before you trust it.

Two details from TradingView's alert variable documentation matter for trading logic specifically:

• {{close}} is the value of the bar on which the alert triggered. {{timenow}} is the fire time, to the nearest second.
• Simple price alerts are calculated on 1-minute bars regardless of the chart timeframe, so the values reflect that resolution and not the candles on your screen.

If your bot sizes an order off {{close}}, you now know exactly what that number is and isn't. It's a reference price, not your fill. That distinction is the whole story behind why a stop order doesn't fill where you set it and why a limit order can sit unfilled while price touches it.

A webhook that arrives is a message. It isn't a fill, and it isn't proof your position matches your chart.

— The Tradoki desk note

Localhost and private addresses never work

If you're building a receiver on your own machine, the errors page is blunt: typos in the URL, localhost or internal IP addresses, and unconfigured domains all produce the "URL unavailable or invalid" error, and URLs that resolve to private addresses are blocked. TradingView's servers can't see your laptop.

For testing you need a public HTTPS endpoint on port 443. Also check the TLS side if you're on a hosted setup. The same page lists incorrect TLS settings and HTTP/HTTPS mismatches as their own error category.

And one more rule from the configuration page that has nothing to do with delivery: don't put credentials or passwords in the webhook body. If your receiver needs authentication, use a secret in the URL path or a verified endpoint, and rotate it if the alert text is ever shared.

Test the whole chain on a demo account first

Everything above is about delivery. None of it tells you whether the order that results is the one you intended. Alerts that trigger on bar close, fire later than the chart suggests, and strategies that look clean in a tester can still behave differently in live conditions.

So run the entire pipeline, alert to webhook to broker, on a demo account first. Force the failure cases on purpose: reply slowly, return a 500, send invalid JSON, and watch what your receiver does. A bot that survives those tests is boring, and boring is exactly what you want from something that places orders while you sleep.

With automated trading, the failures are rarely in the signal. They're in the plumbing nobody tested.

● FAQ

Why is my TradingView webhook not working?

Start with the Webhook status column in the alert log, because it tells you whether TradingView sent the request and what came back. The usual causes in TradingView's own docs are 2FA not enabled, a port other than 80 or 443, a receiver that takes longer than three seconds to answer, an IPv6-only endpoint, or a URL that resolves to a private address.

How long does TradingView wait for my server to respond to a webhook?

Three seconds. If the receiving server takes longer to process the request, TradingView cancels it and the alert log shows a timeout. If your endpoint does slow work before replying, such as calling a broker API, that work is what runs you over the limit.

Does TradingView retry a failed webhook?

In one documented case, yes. If the receiver returns a 5xx status code other than 504, TradingView sends the notification again after 5 seconds, up to 3 resends. That means one alert can reach your server up to four times, so the receiving side has to tolerate duplicates.

Why does my webhook arrive as plain text instead of JSON?

TradingView only sends an application/json content-type header when the alert message is valid JSON. Otherwise it sends text/plain. A common cause is an unquoted string placeholder, since a ticker substituted into a JSON field without quotes produces a message that is not valid JSON.

Can I send a TradingView webhook to localhost?

No. TradingView lists localhost and internal addresses among the causes of its URL-unavailable error, and it blocks URLs that resolve to private IPs. For testing you need an endpoint that is reachable from the public internet on port 80 or 443.