TradingView Webhook Not Working? Fix Failed Alerts, Timeouts, and 4xx/5xx Errors

TradingView webhook failure diagnostic showing timeout, 4xx, 5xx, JSON, and URL checks

TLDR: When a TradingView webhook is not working, begin with the alert log's Webhook status column. A missing alert, a failed webhook, a successful webhook with no downstream order, and a broker-rejected order are four different problems. Common webhook causes include disabled two-factor authentication, an invalid or private URL, unsupported ports, bad TLS, invalid JSON, authorization errors, rate limits, server failures, and TradingView's three-second response timeout. This guide helps identify the broken layer. If maintaining the webhook, middleware, and broker API chain is the problem itself, Ultra Mega Trader offers an alternative that uses TradingView's existing browser and broker connection without webhooks or external API keys.

Ultra Mega Trader · TradingView & NinjaTrader

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 Webhook Not Working? Start Here

Do not change several settings at once. First determine whether TradingView generated the alert and whether it attempted the webhook.

  1. Open TradingView's Alerts panel.
  2. Open the Alert log.
  3. Find the exact trigger time.
  4. Check whether an alert entry exists.
  5. Review the Webhook status and any displayed error.

Use this quick classification:

What you see Most likely layer Next action
No alert in the log Strategy, condition, frequency, expiration, or alert configuration Inspect the alert itself before debugging the webhook
Alert exists and Webhook status failed URL, network, TLS, payload, authorization, or receiving server Match the error to the fixes below
Webhook shows success but middleware received nothing useful Payload parsing, routing, logging, or service configuration Compare the raw request with the service's expected format
Middleware received the signal but no broker order appeared Symbol mapping, quantity, API credentials, permissions, market session, or broker rejection Inspect middleware and broker order logs

If the TradingView alert fired but no broker order appeared, continue with our layer-by-layer guide: TradingView Alert Triggered but No Broker Order Was Placed.

1. Enable Two-Factor Authentication

TradingView requires two-factor authentication before webhook alerts can be used. If the Webhook URL option is unavailable or a previously configured workflow has changed, confirm that 2FA remains enabled on the TradingView account.

This is an account requirement, not a setting on the receiving server.

2. Check the Webhook URL for Typos and Redirects

A single incorrect character, expired token, changed path, or missing route can break delivery. Copy the destination URL directly from the receiving platform rather than retyping it.

TradingView categorizes 3xx responses as redirects. Common causes include:

  • The domain or endpoint path changed.
  • The URL redirects to a login page.
  • A proxy or security layer forces a different destination.

A browser successfully opening a URL does not prove that the endpoint accepts a TradingView POST request without redirection.

3. Use a Publicly Reachable URL, Not Localhost

TradingView's servers cannot deliver to localhost, a private LAN address, or an endpoint that resolves to an internal IP. Examples that will not work as public webhook destinations include addresses beginning with 127.0.0.1, 192.168.x.x, or other private ranges.

A do-it-yourself receiver must be accessible from the public internet and secured appropriately. A temporary tunnel can also fail when its URL changes or the local tunnel stops running.

4. Use Port 80 or 443

TradingView only accepts webhook URLs using destination ports 80 and 443. A development server running on ports such as 3000, 5000, or 8080 cannot be called directly by adding that port to the webhook URL.

Put the receiving application behind an approved HTTP or HTTPS endpoint, or use a service designed to receive TradingView webhooks.

5. Check HTTPS and TLS Configuration

Secure-connection errors can be caused by an expired certificate, incomplete certificate chain, unsupported TLS settings, hostname mismatch, or a proxy responding differently from the origin server.

If the error says the connection does not look secure or a secure connection could not be established, repair the endpoint's certificate and TLS configuration. Do not place broker passwords, account credentials, or sensitive secrets inside the alert body.

6. Validate the JSON Message

TradingView sends a valid JSON alert message with an application/json content-type header. If the message is not valid JSON, TradingView sends it as text/plain.

That difference can cause a receiver to reject a message that looks correct on the screen. Common JSON errors include:

  • Missing quotation marks around keys or string values.
  • A trailing comma.
  • Unescaped quotation marks inside a value.
  • Missing braces.
  • Placeholders resolving to unexpected text.
  • Incorrect field names for the receiving service.

Validate the final message after TradingView placeholders have been considered, not only the template before values are inserted.

7. Fix 4xx Client Errors

A 4xx status means the receiving server rejected the request. TradingView lists several common causes:

  • The endpoint does not exist.
  • Authorization failed.
  • The request contains invalid data.
  • The account exceeded a rate limit.

Examples include 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, and 429 Too Many Requests.

Check the receiving service's logs for the exact response body. A webhook token may have expired, an API credential may lack trading permission, or the payload may contain a symbol or action the service does not recognize.

8. Investigate 5xx Server Errors

A 5xx response means the destination received a valid request but could not process it successfully. The receiving server may be unavailable, overloaded, misconfigured, or failing inside its application code.

TradingView currently documents webhook resubmission for HTTP responses from 500 through 599, except 504. It may resend after five seconds, with up to three resends in addition to the original attempt.

This creates an important execution concern: a receiver should be designed to recognize duplicate messages. Otherwise, a retry can potentially become another order. Confirm the current retry behavior with TradingView and the receiving service before relying on it.

9. Respond Within Three Seconds

TradingView cancels a webhook request if the receiving server takes longer than three seconds to respond. A server that waits for the broker API, position lookup, risk calculation, or order confirmation before replying may exceed that window.

The Alert log may show a timeout even if the receiver started processing the request. That ambiguity is dangerous for trading automation because blindly sending the message again could create a duplicate order.

A properly engineered receiver generally acknowledges valid receipt quickly and handles longer processing separately, with idempotency and broker-order reconciliation. That architecture requires more than a simple webhook script.

10. Confirm IPv4 and DNS Reachability

TradingView states that IPv6 is not currently supported for webhooks. Confirm that the hostname resolves to a publicly reachable IPv4 destination.

Errors such as “couldn't find this domain,” “server couldn't be reached,” or “URL unavailable” can also come from DNS configuration, an expired domain, a disabled tunnel, a firewall, a restricted IP, or a temporary network failure.

Test DNS resolution and endpoint reachability from outside your own network. A server working locally does not prove TradingView can reach it.

Additional TradingView Alert Checks

Is the Alert Still Active?

Check the alert's expiration and whether TradingView stopped it. TradingView notes that an alert based on alert() calls automatically stops if it triggers more than 15 times within three minutes.

Did You Change the Strategy After Creating the Alert?

When a strategy alert is created, TradingView saves a server-side copy of the strategy, its inputs, the chart symbol, and the timeframe. Later chart or strategy changes do not update that running copy. Delete and recreate the alert when the strategy context changes.

Did You Choose the Correct Alert Event?

A strategy alert can be configured for order-fill events, alert() function calls, or both. Choosing the wrong event type can create extra messages or no message at the moment you expected.

Safe Webhook Testing Checklist

  1. Use paper trading or a broker simulator.
  2. Reduce quantity to the smallest valid test size.
  3. Send the alert first to a secure request inspector that does not contain broker credentials.
  4. Verify the raw headers, content type, and message body.
  5. Point the alert to the middleware and verify its signal log.
  6. Confirm the broker received exactly one order.
  7. Test entries, exits, reversals, duplicate messages, and rejected orders.
  8. Reconcile TradingView, receiver, middleware, and broker timestamps.

When the Webhook Stack Is the Problem

Fixing a webhook is reasonable when the trader needs a custom server-side system. But if the goal is simply to automate a TradingView strategy through a broker already supported inside TradingView, the external stack may add more complexity than value.

A webhook trading setup can require:

  • A paid TradingView plan with webhook access.
  • A public webhook receiver.
  • JSON command templates.
  • A middleware or trade-copier subscription.
  • Broker or exchange API credentials.
  • Symbol mapping and quantity conversion.
  • Retry, duplicate-order, and reconciliation logic.
  • Logs across multiple services.

A TradingView Automation Alternative Without Webhooks

Ultra Mega Trader Automator uses a different architecture. It runs in the browser with TradingView and the broker connection opened by the user inside TradingView. It does not require a webhook URL, JSON payload, custom middleware, or separate broker API keys.

This removes the HTTP-delivery and external-message-processing layers described in this guide. It does not remove every dependency. TradingView and UMT must remain open, the connection must remain stable, the strategy must be configured correctly, and the exact market must be supported by the TradingView broker connection and account.

For the complete workflow, read How to Automate TradingView Trades Without Webhooks, API Keys, or Code.

Tired of maintaining the webhook-to-middleware-to-API chain? Start a free seven-day UMT trial by contacting support@ultramegatrader.com. Use the getting-started guide and validate the entire workflow in paper trading first.

TradingView Webhook FAQ

Why is my TradingView webhook timing out?

TradingView cancels a request when the receiving server does not respond within three seconds. Server load, network problems, synchronous broker processing, or slow application code can cause the timeout.

What does a TradingView webhook 403 error mean?

A 403 generally means the receiving server understood the request but refused it. Check authorization tokens, IP allowlists, account permissions, firewall rules, and the destination service's logs.

Why does TradingView say my webhook URL is invalid?

Possible causes include a typo, unsupported port, localhost or private IP, DNS failure, an unreachable domain, IPv6-only resolution, or a blocked URL.

Does TradingView retry failed webhooks?

TradingView currently documents up to three resends after the original request for HTTP 500–599 responses, except 504, with five seconds between attempts. Confirm current behavior and use duplicate-message protection.

Why did my alert fire but my broker receive no order?

A successful alert is not proof of a successful broker order. The failure may be in webhook delivery, message parsing, symbol mapping, API authentication, market hours, account permissions, risk checks, or the broker's rejection response.

Can I automate TradingView without debugging webhooks?

UMT provides a browser-based alternative through TradingView's existing broker connection. It removes the webhook receiver, JSON payload, middleware, and separate broker API keys from the workflow.

Sources

Educational content only. Automated trading involves risk of loss. A successful alert or webhook does not guarantee broker acceptance, a fill, a particular execution price, or profitability. Do not include sensitive credentials in webhook bodies. Test all changes with paper trading before considering live capital.

Back to blog