TradingView's alert webhooks are the most-used signal-delivery mechanism in retail trading by an order of magnitude. They are also the source of more silent failures than any other component in the typical retail trading stack. The protocol is simple enough to look bulletproof — TradingView sends an HTTP POST when your alert fires, your endpoint receives it, your routing layer executes the trade — but the implementation realities make the failure modes plentiful, the failure signatures invisible to the alert author, and the recovery story usually 'I noticed the strategy stopped firing three days ago, what happened?'.
This article is the long-form practitioner's guide to TradingView webhook reliability. It covers every silent failure mode we have debugged in PipSync support tickets over the past two years, the receiver architecture that actually survives the busy minutes (FOMC, NFP, BTC liquidations), the message-format conventions that prevent parsing surprises, and the operational disciplines that separate working pipelines from frustrated traders staring at unfired alerts.
How TradingView webhooks actually work
When you create a TradingView alert and configure it with a webhook URL, the alert is registered in TradingView's alert engine. When the alert condition fires, TradingView's backend generates an HTTP POST to the configured URL with the configured body (which can include placeholder substitutions for the current price, timestamp, ticker, etc.).
Critical properties of the protocol that almost nobody documents clearly:
- Fire-and-forget: TradingView does not retry on failure. If the first POST fails for any reason, the alert is logged as 'fired' from TradingView's perspective and not retried.
- Short timeout: the timeout for the webhook POST is approximately 5 seconds. Receivers that take longer to respond have their alert dropped.
- Single POST: the alert fires once per condition match. There is no batching or retry-on-batch.
- Limited error surfacing: TradingView's alert log shows the alert fired but does not show whether the receiver acknowledged. From the alert-author's view, a successful delivery and a failed delivery are visually identical in the alert history.
- Frequency caps: alerts on free and Pro plans have per-tier limits on how often a single alert can re-fire. Exceeding the cap silently throttles further fires.
Each of these properties is independently fine. Stacked together they produce a protocol where the alert author has no good way to know whether their pipeline is working, and the failure modes are systematically biased toward 'silent drop' rather than 'visible error'.
Every drop mode we have actually debugged
1. Frequency cap exceeded
TradingView's pricing tiers each have a maximum alert count and a maximum fire frequency. Free-tier users get something like 1 alert; Pro users get 20; Pro+ 100; Premium 400. The frequency cap is less-documented — it limits how often a single alert can fire in a given window. Exceeding the cap doesn't throw an error; the alert silently fails to fire on the throttled invocations.
Symptom: 'My alert worked yesterday, today it isn't firing.' Usually because the alert author crossed into a higher-volatility instrument or a different timeframe and the alert is now firing more frequently than the throttle allows.
Fix: upgrade plan, or restructure the alert to fire less frequently (use a longer timeframe, a more restrictive condition, or batch multiple conditions into one alert).
2. Receiver timeout
TradingView's ~5-second webhook timeout is generous in absolute terms but tight in practice. A receiver endpoint that processes the alert synchronously — looking up account state, validating against risk rules, computing position size, submitting the broker order, waiting for the broker ACK — can easily run 3-8 seconds in the slow case. During the slow case the alert times out and is silently dropped.
Symptom: 'My alerts work most of the time but I'm noticing occasional drops, especially around news.' Usually because the receiver's downstream dependencies (broker API) slow down during high-volume periods, pushing the synchronous receiver past the timeout.
Fix: receiver MUST acknowledge the POST in under 500ms ideally, under 200ms preferably. Architecture: receive POST → write to durable queue → return 200 OK. All actual processing happens asynchronously off the queue.
3. Message-body format mismatch
TradingView accepts any string in the alert body. The most common format for routing platforms is JSON, but the alert body is free text — there's no validation of the JSON structure at TradingView's end. Common breakages: extra commas, trailing newlines, unescaped quotes inside string values, Unicode characters from copy-paste, missing required fields.
The receiver gets the body, attempts to parse, fails, and either logs the failure and drops the alert or returns a 400. From the alert author's perspective the alert fired and the receiver didn't act on it; the diagnostics are buried in the receiver's logs that most users don't routinely check.
Fix: use simple, robust JSON in the alert body. Test the exact body string in a JSON validator before activating the alert. PipSync's webhook ingest writes every received body to the audit log regardless of parse outcome — if the alert reached us, the body is in the audit log with the parse failure reason. Most webhook-drop tickets get resolved in under ten minutes by looking at that log.
4. SSL/TLS handshake failure
TradingView only delivers webhooks to HTTPS endpoints (since 2024). The TLS handshake itself has been a source of intermittent drops when receiver TLS configurations are old or unusual. Most commonly: receivers with expiring certificates, receivers using cipher suites that TradingView's outbound client doesn't accept, receivers behind CDNs with their own TLS config issues.
Symptom: alerts work for weeks, then suddenly stop for a specific endpoint while other endpoints continue to work. Usually a TLS certificate has expired or the CDN has rotated to a config TradingView's client doesn't like.
Fix: monitor TLS expiry actively, use a TLS configuration that passes the SSLLabs grade A test, prefer endpoint hosting on a major cloud provider with managed TLS over self-managed reverse proxies.
5. Receiver IP-based rate limiting
TradingView's webhook source IPs are not always the same; they're a pool. If your receiver runs aggressive IP-based rate limiting (intended to block scraping or DDoS), it can inadvertently block legitimate TradingView traffic during high-volume periods. Symptom: alerts work normally during quiet markets, fail intermittently during high-volume sessions.
Fix: allowlist TradingView's webhook source IP ranges, or remove IP-based rate limiting from the webhook endpoint and replace with token-based authentication that bounds total request rate without per-IP throttling.
6. Receiver auth failure on token rotation
Sophisticated routing setups require authentication headers in the webhook body (bearer token, HMAC signature, shared secret). When the token is rotated and TradingView's alert is not updated with the new value, the receiver rejects the POST as unauthorised. Symptom: all alerts to a specific endpoint suddenly stop firing.
Fix: when rotating auth tokens, update the TradingView alert configurations before deactivating the old token. Maintain a rotation schedule that lets the old token continue working for a grace period (24-48 hours) while updates propagate.
The receiver architecture that actually survives
Building a webhook receiver that handles 99.5%+ of legitimate alerts across all of the above failure modes requires a specific architecture. The pattern that works:
- Edge receiver — a lightweight HTTP endpoint that does only three things: validates the auth header (HMAC or bearer token), writes the raw body to a durable queue, and returns 200 OK. Total latency under 100ms in the slow case.
- Durable queue — RabbitMQ, Kafka, SQS, Redis Streams, or any equivalent. The queue persists the message so receiver crashes don't lose alerts.
- Async processor — the actual signal-routing logic runs from the queue. It can take 30 seconds if it needs to; the original webhook is long since acknowledged. Failures in the processor get retried from the queue with exponential backoff.
- Structured audit log — every received body, parse outcome, and downstream action gets logged with a correlation ID that ties the original webhook to the eventual broker order.
- Observable health — the receiver exposes metrics on request rate, error rate, queue depth, and processor lag. Alerts on those metrics catch problems before users notice missing trades.
The setup we recommend for active alert users
- Premium TradingView plan if you depend on more than a handful of alerts. The frequency caps on lower tiers will bite you eventually.
- JSON body with explicit symbol, direction, entry, stop, and target fields — even when they're technically computable. Explicit fields fail loudly; implicit fields fail silently.
- Webhook receiver with the queue-based architecture above. Acknowledge fast, process slow.
- Active TLS monitoring — Cloudflare, Pingdom, or equivalent — with alerts that fire when the receiver TLS goes sideways.
- Duplicate critical alerts to a second independent receiver during the first 30 days of any new strategy, so you can A/B compare delivery rates and confirm both receivers see the same alerts. Once the rates match, retire the secondary.
- Audit your TradingView alert log monthly. The TradingView UI shows when alerts fired. Cross-reference against your receiver's audit log to spot drops.
What still goes wrong even with all of the above
TradingView's webhook delivery itself can have outages. The TradingView status page (status.tradingview.com) documents them when they're broad enough to be obvious; smaller delivery issues sometimes don't get acknowledged. There's no SLA on webhook delivery, and there's no support escalation path that meaningfully improves it. For strategies where individual alert reliability matters more than the average, the only real defence is redundancy — multiple alert sources covering the same signal, or running TradingView alerts in parallel with a Pine-script implementation routed via a different channel.
The other class of failure that doesn't get fixed by good architecture: alert configuration errors. The user accidentally changes the alert symbol when editing a chart and doesn't notice. The user toggles 'once per bar close' to 'once per bar' without realising the implications. The user accidentally deactivates the alert by closing the alert dialog without saving. These are user-error problems, not architecture problems, and they account for a meaningful fraction of 'my alerts aren't firing' tickets.