TLDR: If a TradingView webhook was not received, first prove that the alert triggered. Then read the Webhook status in TradingView's alert log and compare its timestamp with logs from the receiving edge, proxy, application, queue, and broker adapter. A missing edge log points toward DNS, TLS, firewall, or routing. An edge log without an application log points toward a proxy or route. An application acceptance without a downstream action points toward parsing, queueing, or broker processing.
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
A webhook is an HTTP POST, not a broker order. Several systems may sit between the TradingView alert and the final action. Treating all of those systems as one black box creates guesswork. A short evidence trail shows where the request actually stopped.
If you would rather avoid operating that webhook chain, UMT Automator provides a browser-based automation workflow for eligible TradingView strategies without a user-configured webhook, JSON payload, broker API key, or custom middleware server.
Did the TradingView Alert Actually Trigger?
Open the Alerts Log and locate the expected event. Record the alert name, trigger time, message, and Webhook status. This divides the investigation immediately:
- No alert-log entry: the condition did not generate an alert event. Inspect the alert condition, frequency, schedule, expiration, and saved strategy or script version.
- Alert entry with failed Webhook status: use the exact error to investigate the delivery layer.
- Alert entry with successful Webhook status: TradingView received a successful HTTP response. Trace processing inside the receiving system.
Do not create multiple live tests before reading this evidence. Repeated alerts can produce duplicate downstream actions if the receiver recovers while testing.
Trace the Webhook Through Five Evidence Points
| Evidence point | What it proves | If it is missing |
|---|---|---|
| TradingView alert log | The alert event existed. | Fix the alert condition or schedule first. |
| CDN, load balancer, or firewall log | The request reached your network edge. | Check URL, DNS, TLS, public access, and firewall policy. |
| Reverse-proxy or route log | The edge forwarded the request to the expected service. | Check host, path, method, redirect, and routing rules. |
| Application and queue log | The receiver parsed and accepted the event. | Check authentication, content type, JSON schema, and application errors. |
| Broker adapter and broker record | The downstream order request was submitted or rejected. | Check account state, mapping, risk controls, and broker response. |
Use one event identifier across the chain when your receiver supports it. At minimum, log the alert name, UTC receive time, sanitized payload fingerprint, processing result, and downstream response. Never log passwords, API keys, session cookies, or complete secrets.
Why Is There No Request in the Edge Logs?
The Webhook URL Is Not Publicly Reachable
TradingView cannot deliver to a localhost address or private network IP. Its webhook documentation also states that only destination ports 80 and 443 are accepted and IPv6 is not supported for webhook delivery. Confirm that the hostname has a usable public IPv4 route and that the exact production path is reachable from outside your own network.
DNS or TLS Failed Before HTTP Began
A domain can open from one cached browser and still fail from another network. Check authoritative DNS, the certificate hostname, expiration, certificate chain, and proxy configuration. A secure-connection error is different from a 4xx application response because the request may never reach the application.
A Firewall Rejected TradingView
Compare firewall activity with TradingView's currently documented webhook sender addresses. If an allowlist is necessary, verify the official address list again before publishing a rule because infrastructure can change. A certificate-based validation method is also documented by TradingView for teams that need stronger sender authentication.
Why Did the Edge See the POST but the Application Did Not?
This usually points to a reverse proxy, API gateway, or routing problem. Check:
- The exact hostname, path, capitalization, and trailing-slash behavior.
- Whether HTTP redirects to a different path or login page.
- Whether the route accepts POST rather than only GET.
- Whether the production deployment contains that route.
- Whether the proxy can reach the upstream application.
- Whether a request-size or content-type policy rejected the body.
Testing only the homepage with a browser does not prove that the POST route works. Send a sanitized test POST to the exact endpoint from an external environment and inspect every response header and log entry.
Why Did the Application Receive the Webhook but No Action Occurred?
At this point, delivery is no longer the primary issue. The application may have rejected the payload, placed it in a stalled queue, discarded it as a duplicate, mapped the symbol incorrectly, or received a broker rejection.
TradingView sends valid JSON with an application/json content type when the alert message is valid JSON. Otherwise, it sends text/plain. Confirm that the receiver handles the actual content type and validates every required field. Return a non-success status when processing cannot safely accept the event. A false success response makes TradingView look healthy while the downstream workflow silently fails.
Could a Successful HTTP Response Still Hide a Failure?
Yes. A CDN, serverless gateway, or proxy can return success before the application processes the request. That architecture is useful for meeting TradingView's three-second response limit, but only if the event is durably queued and observable.
A robust receiver should:
- Validate essential authentication and schema quickly.
- Store or enqueue the accepted event durably.
- Return an HTTP response within the delivery limit.
- Process the broker workflow asynchronously.
- Record success, rejection, retry, and duplicate outcomes.
A Safe TradingView Webhook Receipt Test
- Use a paper-trading or otherwise non-live destination.
- Create one controlled alert with a unique test identifier.
- Keep the payload free of passwords and sensitive credentials.
- Trigger it once.
- Capture TradingView's log status and each receiver-side timestamp.
- Stop the test before making another change.
This produces a reliable before-and-after result without turning troubleshooting into an order-duplication risk.
How UMT Automator Changes the Troubleshooting Surface
UMT Automator is software that connects supported TradingView strategy activity with broker-side automated trade execution through a browser-based workflow. It does not require the user to host a webhook receiver, write JSON alert messages, maintain API credentials, or operate middleware.
That removes the DNS, TLS, firewall, receiver, and queue layers described above from the user's setup. It does not remove market risk, broker behavior, device availability, internet requirements, or the need to test the strategy. Review the requirements and use paper trading first.
Review the UMT Automator setup process, then start the current free 7-day UMT Automator trial to evaluate the workflow with an eligible TradingView strategy.
Frequently Asked Questions
How do I know whether TradingView sent my webhook?
Find the event in the Alerts Log and inspect its Webhook status. Then compare the trigger time with your edge and application logs. An alert trigger and a received application event are separate facts.
Why does TradingView show success when my app received nothing?
An intermediate proxy or gateway may have returned a successful response. Check which component generated the response and whether it durably forwarded or queued the request.
Does TradingView resend failed webhooks?
TradingView documents resubmission for HTTP 500 through 599 responses except 504. It may resend after five seconds up to three times after the original request. Receivers should therefore be able to identify duplicate events.
Can UMT Automator work without my own webhook server?
Yes. UMT Automator's browser-based workflow does not require the user to configure a webhook server, JSON payload, broker API key, or custom middleware. Confirm the current platform and strategy requirements before starting.
Risk disclaimer: Automated trading involves substantial risk. Test configurations in simulation or paper trading before live use. Software and delivery workflows cannot guarantee alerts, execution, fills, synchronization, or trading results.
