TLDR: A TradingView webhook status of failed means the webhook delivery did not complete normally; it does not automatically mean the strategy failed or the broker rejected an order. Open the alert log, capture the exact HTTP or delivery error, and diagnose that layer first. A 3xx points to a redirect, 4xx to the request or authorization, 5xx to the receiving server, and a timeout to a receiver that did not answer within TradingView’s three-second limit. If you want to eliminate the webhook layer entirely, UMT automates eligible TradingView strategies through the browser without a user-configured webhook.
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
“Webhook status failed” is useful only after you identify what failed. A TradingView automation chain can contain a strategy, alert event, webhook delivery, middleware, broker API request, live order, and fill. Each stage has a different log and a different fix.
This guide focuses specifically on the webhook status shown in TradingView’s alert history. If the alert never triggered at all, start with TradingView Strategy Alerts Not Working. If the webhook shows success but no live order appeared, use TradingView Alerts vs Broker Orders.
First: Identify Which of These Three Cases You Have
Case 1: No alert event appears
This is not yet a webhook-status problem. The strategy or alert condition may not have triggered in realtime, the alert may be expired or stopped, or the active alert may contain an older saved copy of the strategy and inputs.
Case 2: The alert appears and the webhook status failed
The alert engine reached the delivery step, but the destination did not complete the expected exchange. Capture the exact error text and time before changing anything.
Case 3: The webhook succeeded but no broker order appeared
The failure is downstream. Check middleware logs, symbol mapping, account selection, quantity, broker permissions, order rejections, and market state. Repeatedly requesting the webhook can create duplicate-order risk.
How to Read the TradingView Webhook Error
TradingView groups failures by standard HTTP behavior and delivery conditions. Use the exact status instead of treating every failure as the same issue.
| Status or error | What it usually means | Where to investigate |
|---|---|---|
| 3xx | The endpoint returned a redirect. | Use the final public HTTPS URL directly; inspect proxy and trailing-slash rules. |
| 400 | The receiver considered the request invalid. | Check JSON syntax, required fields, schema, and content type. |
| 401 or 403 | Authentication or authorization failed. | Check tokens, secret path, firewall, WAF, IP rules, and route permissions. |
| 404 | The route does not exist at that URL. | Check domain, path, deployment, environment, and capitalization. |
| 408 or timeout | The request did not complete in time. | Make the receiver acknowledge quickly and move slow work to a queue. |
| 429 | The receiver rate-limited the request. | Review alert bursts, receiver limits, and safe queue capacity. |
| 5xx | The destination server or upstream service failed. | Inspect application, proxy, database, queue, and provider logs. |
| TLS or certificate error | TradingView could not establish a secure HTTPS connection. | Check certificate validity, hostname, chain, protocol, and proxy configuration. |
| Invalid URL or private IP | The target cannot be used as a public webhook destination. | Use a valid public URL on an accepted port; do not target localhost or a private address. |
| Unknown or network error | Delivery could not be completed or classified cleanly. | Correlate the time with DNS, proxy, hosting, and receiver-access logs. |
A Five-Minute Diagnostic Sequence
- Record the evidence. Save the alert name, trigger time, exact webhook status, HTTP code, and sanitized message. Do not expose credentials in screenshots or support tickets.
- Confirm the exact URL. Check the scheme, hostname, path, secret segment, and environment. TradingView accepts webhook destination ports 80 and 443 and does not support IPv6 targets.
- Check receiver access logs. If no request appears at the matching time, investigate DNS, TLS, firewall, WAF, public routing, or the URL itself.
- If the request appears, match its result. A 4xx means the receiver deliberately rejected it. A 5xx means the receiver failed while handling it.
- Measure response time. TradingView cancels a request that takes longer than three seconds. The endpoint should validate, enqueue, and acknowledge before doing slow broker work.
- Trace downstream separately. If the receiver accepted the event, follow its correlation ID through the queue, execution worker, broker response, and fill records.
Fixes by Failure Type
Redirect status
Put the final HTTPS endpoint in the TradingView alert. Common redirect sources include HTTP-to-HTTPS rules, a missing or extra trailing slash, an old domain, and authentication gateways. Do not assume the delivery system will follow a redirect exactly like a browser.
403 Forbidden
Verify the current token or secret path, the route’s access policy, proxy rules, and any source-IP allowlist. A browser loading the domain successfully does not prove that the webhook POST is authorized. See the dedicated TradingView Webhook 403 Error guide.
Invalid JSON or 400 response
Validate the final message after TradingView placeholders expand. Check double quotes, commas, braces, line breaks, and the receiver’s required fields. Valid JSON is sent as application/json; other text uses text/plain. Follow the invalid JSON checklist.
Timeout
Do not make the initial request wait for broker placement, a slow database, or notification services. Store the event durably, return quickly, and process it asynchronously. A longer timeout setting on your own client does not change TradingView’s three-second limit.
5xx server error
Inspect the receiver at the exact alert time. Look for application exceptions, deployment restarts, exhausted connections, queue or database outages, and upstream provider failures. TradingView documents resubmission for some 500–599 responses, so the receiver must prevent duplicate execution.
Do Not Repeatedly Press Test or Recreate the Alert
Changing several layers at once destroys evidence. Worse, resending a signal after an uncertain server response can place an additional order if the first request reached the broker but the acknowledgment was lost.
Make one controlled change, send one non-live or paper-trading test, and trace it end to end. Use an event or correlation ID so the same signal can be recognized across TradingView, the webhook server, and the broker.
When the Status Is Successful but Trading Still Fails
A successful webhook means the endpoint returned a successful HTTP response. It does not prove that:
- The message was semantically valid for the middleware.
- The symbol mapped to the intended broker instrument.
- The account had sufficient permissions or buying power.
- The broker accepted the order.
- The market filled the order.
Your receiver should expose separate states for received, validated, queued, submitted, accepted, rejected, partially filled, and filled. If it reports only “success,” consult broker records before sending another order.
Remove the Webhook Failure Layer with UMT
If webhook maintenance is the recurring problem, UMT Automator offers a different architecture. It automates eligible TradingView strategy workflows through the browser with a supported broker connected inside TradingView. There is no webhook URL, JSON payload, public receiver, or broker API key for the user to configure in UMT.
This does not eliminate every operational dependency. The required TradingView tab, browser session, and internet connection must stay active, and broker compatibility depends on TradingView and account permissions. Test in paper trading before using live capital.
Want fewer delivery layers between your TradingView strategy and broker? Review the UMT Trade Automator or compare TradingView webhook alternatives. Contact support@ultramegatrader.com for a seven-day trial.
Frequently Asked Questions
Why does TradingView say my webhook failed?
The URL may have redirected, rejected the request, timed out, returned a server error, or failed a network, DNS, or TLS check. The exact status in the alert log identifies the next layer to inspect.
Does a failed webhook status mean my strategy did not trigger?
Not necessarily. If an alert event appears with a delivery failure, the condition triggered and the problem occurred during webhook delivery.
How long can a TradingView webhook take?
TradingView documents that it cancels the request when the remote server takes longer than three seconds.
Should I resend after a failed status?
First determine whether the initial event reached the receiver or broker. Resending without reconciliation can create a duplicate order. Use paper trading for controlled tests.
Does UMT have a webhook status?
UMT does not use a user-configured TradingView webhook in its browser-based workflow, so this specific webhook-delivery layer is removed.
