Debugging Webhooks That Do Not Fire

Almost every wasted hour in webhook debugging comes from investigating the wrong half of the pipeline. This is ordered to prevent that.

Step one: check the alert log

TradingView acknowledges that webhooks may occasionally fail to reach the specified URL, and provides a webhook status column in the alert log for monitoring delivery.

Look there first, before touching your endpoint. It answers the only question that matters at this stage: did TradingView attempt the request?

If there is no alert entry at all, the alert did not fire and the problem is the alert or its condition. If there is an entry with a failed status, the request was attempted and something at the network or endpoint level rejected it. Those are entirely different investigations.

If the alert never fired

Plan does not support webhooks. The free Basic plan cannot send them at all. This is the single most common cause of a new setup doing nothing. If the webhook field is missing or greyed out in the alert dialog, that is your answer.

Two-factor authentication is not enabled. TradingView permits webhook alerts only when 2FA is active on the account. Enable it and recreate the alert.

The alert expired. Alerts expire on most tiers and stop firing silently. An expired alert produces exactly the symptom of a broken endpoint: nothing happens, no error anywhere. Check the expiry date before assuming a technical fault.

The condition was never met. Unglamorous and common. Plot the condition with plotshape to see where it would have triggered historically. If the markers are not where you expect, the logic is wrong rather than the plumbing.

Frequency settings. An alert set to fire once and only once has already done so. Bar-close frequency will not fire on an intrabar condition that resolves before the close.

Wrong alert target. An alert attached to a different indicator instance, or to a chart with a different timeframe or symbol than you are watching.

If it fired but did not arrive

Now the constraints on TradingView's side become the checklist, and they are narrow enough that most failures are one of them.

Port. Only 80 and 443 are accepted; requests to other ports are rejected. An endpoint on a development port is unreachable no matter how correct the code is.

IPv6. Not supported for webhooks. An endpoint resolving only to an IPv6 address cannot be reached. Confirm an A record exists, not just AAAA.

Three-second timeout. A request taking longer than three seconds is cancelled. If your handler authenticates to a broker and waits for order confirmation before responding, you will exceed it under normal conditions and blow through it under load. Keeping the acknowledgement fast while broker work continues behind it is a high-concurrency I/O problem, not a code-optimisation one. Acknowledge immediately and process behind the response.

Not publicly reachable. Localhost, a private address, or anything behind a firewall without an inbound rule. Test from outside your own network rather than from the machine running the service.

TLS problems. An expired or misconfigured certificate causes a rejection that looks like unreachability. Check the certificate chain from an external tool.

An IP allowlist that went stale. If you restricted inbound traffic to TradingView's published addresses, note that those change. A stale allowlist silently drops legitimate alerts and looks identical to an endpoint being down.

If it arrived but nothing happened

The subtlest category, because the request completed successfully by every external measure.

The body was not valid JSON. TradingView sends an application/json content type only when the message parses as valid JSON; otherwise it sends text/plain, which most trading endpoints reject. A single trailing comma, an unquoted key, or a placeholder that resolved to empty is enough. This is the most common cause in this category and the least visible, because the alert log shows a successful send.

Placeholders did not resolve. Strategy placeholders in a non-strategy alert appear as literal text, which usually breaks parsing.

The secret did not match. Your receiver rejected the request. Log rejections, otherwise this is invisible.

Deduplication suppressed it. If your idempotency key is too broad, a legitimate second signal looks like a repeat and is dropped. This produces missing trades rather than duplicates, which is harder to notice.

The receiver returned a non-2xx. There is no retry. That signal is gone.

Instrumenting so this is not guesswork

Most webhook debugging is hard because nobody logged the thing that would have answered it.

Log the raw body of every request before parsing, including rejected ones. TradingView keeps no sending-side record of the payload you can inspect, so if you did not capture it, it is gone.

Log rejections with a reason. An endpoint that silently drops bad requests gives you nothing to work with.

Emit a heartbeat. A pipeline that has been silent for three hours is either a quiet market or a dead component, and you should not have to guess which.

Reconcile against the broker independently. Your receiver's idea of your positions can drift, and the broker is authoritative.

Reproducing without waiting for the market

Point the alert at a request inspector and fire it manually. Read what actually arrived: whether the request came, the content type, and whether every value resolved.

Then replay that exact captured body against your endpoint with a command-line HTTP client. If it succeeds there but fails from TradingView, the difference is transport — port, TLS, reachability, or timeout. If it fails both ways, it is your handler.

That single split resolves most cases faster than any amount of reading code.

The honest limits

Some signal loss is designed in. One attempt, no retry, no delivery guarantee. A perfectly debugged pipeline still misses alerts occasionally, and building as though it will not is the actual error.

Which means the important question is not only why a webhook failed but what happens when one does. If a missed alert leaves an unmanaged position, the fix is not better debugging — it is exits that rest at the broker rather than depending on a future request arriving.

Running the endpoint on self-hosted infrastructure gives you the logs, network policy, and access to diagnose all of this, and hands you responsibility for keeping it up. And position sizing remains the control that bounds what any single failure costs — capital divided by twenty as the ceiling per position, under the divide-by-20 rule.

Frequently asked questions

How do I tell whether TradingView actually sent my webhook? Check the webhook status column in the alert log. It shows delivery attempts and splits the problem between the alert and your endpoint.

Why is my TradingView webhook not firing at all? Most often the plan does not support webhooks, 2FA is not enabled, the alert expired, or the condition was never met.

Why does my endpoint never receive the request? Port other than 80 or 443, IPv6-only resolution, exceeding the three-second timeout, not publicly reachable, a TLS problem, or a stale IP allowlist.

The request arrives but nothing happens. Why? Usually the body is not valid JSON, so the content type is text/plain and your receiver rejects it.

Does TradingView retry a failed webhook? No. One attempt per fire. A failed delivery is a lost signal.

Disclaimer: This article is educational content about software engineering and trading automation. It is not investment advice, financial advice, tax advice, legal advice, or a recommendation to buy or sell any security. Any instruments named are used solely to illustrate mechanics. Options trading involves substantial risk of loss and is not suitable for all investors. Please read Characteristics and Risks of Standardized Options before trading options. Automated trading systems carry additional risks including software defects, missed or duplicated signals, network and connectivity failures, third-party service changes and outages, and unintended order behaviour that may prevent orders from being placed, modified, or cancelled. Stop orders do not guarantee an execution price and stop-limit orders may not execute at all. Past performance does not indicate future results, and no configuration, alert setup, position-sizing rule, or risk setting can guarantee a profit or prevent a loss.

StaxInvesting LLC sells self-hosted trading software. It is not a broker-dealer, investment adviser, or financial institution, and it does not manage accounts, hold member funds, place trades on behalf of members, or access member brokerage accounts. Members run the software in their own cloud environment, connect their own brokerage accounts under their own credentials, and are solely responsible for their configuration, their credential security, their compliance with third-party terms of service, and every trade executed in their account. Third-party platform details described here reflect publicly available documentation as of publication and are subject to change without notice; always verify against current official documentation. Consult a qualified financial adviser and tax professional regarding your individual circumstances.