TLDR: If your TradingView webhook is not sending, open the Alerts Log before changing the alert or server. No trigger in the log usually means the alert condition never fired or the alert is inactive. A trigger with a failed Webhook status means TradingView attempted delivery and recorded an error. A successful status with no trade means the problem is probably downstream of TradingView. Preserve the evidence, identify the failed layer, and make one controlled paper-trading test.
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
TradingView sends a webhook as an HTTP POST when an enabled alert triggers. The receiving URL, request body, server response, and any later broker order are separate parts of the workflow. “Not sending” can therefore describe several very different failures.
If webhook infrastructure is the recurring obstacle, UMT Automator provides a browser-based path for eligible TradingView strategies without a user-configured webhook, JSON payload, broker API key, or custom middleware server. The troubleshooting steps below come first because the safest next action depends on what your logs show.
Is TradingView Actually Failing to Send the Webhook?
Start by locating the expected trigger time in TradingView's Alerts Log. Enable the Webhook status column if it is hidden. Then place the incident into one of these three cases:
| What you see | What it means | Where to investigate |
|---|---|---|
| No alert trigger in the log | There was no webhook event to send. | Alert condition, status, expiration, frequency, symbol, timeframe, or saved settings. |
| Alert trigger with failed Webhook status | The alert fired, but delivery did not complete normally. | Exact HTTP code, URL, DNS, TLS, firewall, authentication, payload, or server response time. |
| Webhook status is successful | The URL returned a successful HTTP response. | Receiver application, queue, broker mapping, order rejection, or fill status. |
This first split prevents a common mistake: rebuilding a server when the alert never triggered, or editing strategy logic when the receiver rejected a valid request.
What If No Alert Trigger Appears in the Log?
If the expected event is absent from the log, the webhook did not have an opportunity to send. Check the alert itself:
- Status: confirm the alert is active, not stopped manually, triggered under an “Only once” setting, or expired.
- Condition: confirm the selected indicator, strategy, price condition, or order-fill event is the one you intended.
- Symbol and timeframe: indicator, strategy, and drawing alerts can depend on the chart interval.
- Frequency: check whether the alert waits for the bar to close or can trigger during the bar.
- Saved settings: TradingView states that changing an indicator's parameters after creating an alert does not automatically update the existing alert. The alert can continue using its original settings.
- Webhook action: edit the alert and verify that the Webhook URL action is enabled with the intended URL.
- Two-factor authentication: TradingView requires 2FA before webhook alerts can be used.
Do not assume a historical strategy marker proves that a realtime alert should have fired. Historical calculations, realtime behavior, alert frequency, and strategy order events can differ. If you change strategy inputs or alert logic, recreate the alert deliberately and test the new version in paper trading.
What Does a Failed Webhook Status Mean?
A failed Webhook status means the alert triggered and TradingView attempted the delivery step. Record the exact error before editing anything. TradingView's current error documentation groups failures into several useful categories:
- 3xx redirect: the URL points somewhere else, redirects to a login page, or passes through a proxy redirect.
- 4xx client error: the destination rejected the URL, credentials, permissions, rate, or request body.
- 5xx server error: the receiving service could not process an otherwise valid request.
- Timeout: the receiving server did not respond within three seconds.
- Invalid or unavailable URL: the domain, path, DNS, or network route is wrong or unreachable.
- Secure connection error: the HTTPS or TLS configuration could not establish a trusted connection.
- Private-address rejection: the destination resolves to localhost, an internal address, or another restricted IP.
- Connection or response error: the server refused, closed, or returned an invalid response.
Use the exact status to choose the next check. A 403 needs an authorization or firewall investigation. A 404 needs a path or deployment check. A timeout needs a faster handler. Treating them all as a generic “webhook problem” wastes time.
Check the Webhook URL and Network Requirements
Compare the URL in the TradingView alert with the receiver's current production endpoint character by character. Check the scheme, hostname, path, secret segment, trailing slash, and environment. A test endpoint and production endpoint may look nearly identical.
TradingView currently documents these delivery requirements:
- Webhook destinations may use ports 80 or 443 only.
- IPv6 webhook targets are not currently supported.
- Localhost and private IP addresses are not valid public destinations.
- The remote server must respond within three seconds.
- HTTPS endpoints need a valid TLS configuration and certificate chain.
If your URL redirects from HTTP to HTTPS, from one path to another, or to an authentication page, enter the final webhook endpoint directly instead of relying on browser-style redirect behavior.
Why Does the Receiver Show No Request?
“Nothing appears in my application log” does not prove that no request reached your infrastructure. The request may have stopped at the CDN, reverse proxy, load balancer, firewall, web application firewall, or authentication gateway before the application handled it.
Check logs in this order:
- DNS and hosting availability for the exact domain.
- CDN, edge, or load-balancer access logs.
- Firewall and WAF events.
- Reverse-proxy route and response logs.
- Application access and error logs.
- Queue or job-worker logs.
- Broker request and order records.
TradingView publishes the following webhook sender addresses as of August 26, 2026: 52.89.214.238, 34.212.75.30, 54.218.53.128, and 52.32.178.7. If your receiver uses an allowlist, compare it with TradingView's official documentation before every deployment because published infrastructure can change. An IP allowlist should be only one security layer, not the only form of authorization.
Check JSON and Content Type
TradingView sends the alert message in the POST body. When the message is valid JSON, TradingView uses the application/json content type. Otherwise, it uses text/plain.
This matters when the receiving application accepts only JSON. A missing quotation mark, extra comma, invalid line break, or placeholder that expands into an unescaped value can change the content type or cause the receiver to return a 400 response.
Validate the final expanded message, not only the template you typed. Compare required field names, symbol format, action, quantity, and allowed values with the receiver's current schema. Never include passwords, login credentials, or broker secrets in the webhook URL or message. TradingView explicitly warns against sending sensitive credentials through alerts.
Fix the Three-Second Response Problem
TradingView cancels the request when the remote server takes longer than three seconds. A receiver should not wait synchronously for a broker API, database report, email notification, or other slow work before responding.
A safer design is:
- Authenticate the request.
- Validate the required fields and risk limits.
- Record a unique event identifier.
- Write the accepted event to a durable queue.
- Return a successful response within the time limit.
- Process broker submission and reconciliation asynchronously.
Do not return success before the event is durably accepted. Otherwise, TradingView can show a successful delivery while the receiver silently loses the work.
Will TradingView Retry a Webhook That Was Not Sent?
TradingView documents limited resubmission for HTTP 500 through 599 responses, except 504. It resends after five seconds and can make three resends after the original request, for a maximum of four sends for one trigger.
This is not a general guarantee of delivery. It also creates duplicate-order risk if the receiver placed an order but returned a 5xx response. Use idempotency controls and reconcile the first event before manually resending anything.
Check TradingView Status Before Rebuilding Your Setup
TradingView maintains an official status page for Alerts and other services. At the time this article was researched on August 26, 2026, the page reported Alerts operational. Service state can change, so check the current status and incident history when many unrelated alerts fail at the same time.
A platform incident is more plausible when multiple alerts and endpoints fail together. One alert failing against one URL is more likely to involve that alert's configuration or the receiving path.
How to Test Without Creating an Accidental Live Trade
- Preserve the original alert-log entry and receiver logs.
- Disable live execution or route the test to paper trading.
- Create a controlled condition you can trigger once.
- Use a unique event or correlation ID in the test payload.
- Confirm the event in the TradingView log.
- Confirm the same event at the edge, application, queue, and paper broker.
- Make only one configuration change before the next test.
Do not repeatedly trigger an uncertain production alert. If the first request reached the broker but its acknowledgment was lost, a second test can create another order.
When a Successful Webhook Still Produces No Trade
A successful Webhook status proves that the destination returned a successful HTTP response. It does not prove that the receiver validated the payload, mapped the symbol, selected the intended account, submitted a broker order, or received a fill.
Trace these states separately:
- Alert triggered.
- Webhook delivered.
- Payload validated.
- Event queued.
- Broker request submitted.
- Order accepted or rejected.
- Order partially or fully filled.
If the receiver reports only “success,” consult the broker's own order records before sending the signal again.
How UMT Removes the Webhook Layer
UMT Automator is software that connects eligible TradingView strategy activity with broker-side automated order execution through a supported browser workflow. It uses the broker connection inside TradingView, so the user does not need to configure a webhook URL, format a JSON alert, maintain middleware, or provide broker API keys to UMT.
UMT is not a universal replacement for every alert integration. It requires a TradingView strategy, a compatible desktop browser, a broker connection available through TradingView, an active TradingView tab, and a stable internet connection. Broker, market, symbol, and order support remain subject to TradingView, the broker, and account permissions.
The current free seven-day UMT Automator trial lets a qualified trader install the browser extension and evaluate the workflow in paper trading. Use the trial to confirm that UMT detects the intended strategy activity, handles the expected entries and exits, uses the correct account and quantity, and fits your browser-based operating requirements. Do not use live capital as the first test.
Want to evaluate strategy automation without maintaining webhook delivery? Review the UMT Automator requirements and current plans, then follow the UMT Getting Started guide. Request the free seven-day trial at support@ultramegatrader.com.
Frequently Asked Questions
Why is my TradingView webhook not sending?
The alert may not have triggered, the Webhook URL action may be disabled or incorrect, or the destination may have rejected, timed out, or failed to receive the request. The Alerts Log and Webhook status identify which branch to investigate first.
How do I know whether TradingView sent the webhook?
Find the trigger in the Alerts Log and inspect its Webhook status. Then correlate the time with edge and application logs at the receiving service.
Why did the alert fire but my server receive nothing?
The request may have failed at DNS, TLS, a firewall, WAF, proxy, authentication gateway, invalid route, or unsupported destination. Check infrastructure logs before the application log.
How long does a TradingView webhook server have to respond?
TradingView currently documents a three-second limit. The receiver should validate and queue the event quickly, then perform slower work asynchronously.
Does TradingView retry failed webhooks?
TradingView documents up to three resends for HTTP 500 through 599 responses except 504, after the original request. Other failures do not necessarily receive the same treatment, so use monitoring and duplicate protection.
Can I automate a TradingView strategy without webhooks?
Yes, for eligible workflows. UMT Automator uses a browser-based approach with a broker connected inside TradingView, without requiring a user-configured webhook, JSON payload, API key, or custom middleware server.
Risk and Reliability Notice
Automated trading involves software, connectivity, broker, market, and execution risk. Webhook delivery, browser availability, broker acceptance, and order fills are not guaranteed. Test the complete workflow in paper trading, use appropriate position and loss limits, monitor open positions, and maintain a procedure for stopping automation and managing orders manually.
