What actually happens when a TradingView alert fires

When a TradingView alert triggers with webhook enabled, TradingView issues an HTTP POST to the URL you specified. The body of that request is whatever text (or JSON) you typed into the alert’s Message field. If the message parses as valid JSON, the request carries an application/json content-type header. If it’s plain text, it arrives as text/plain. That’s the entire contract on TradingView’s side.

Everything else — authentication, routing, order sizing, risk checks — happens on the receiving end. TradingView does not sign the request, does not retry on failure, and does not wait around. According to TradingView’s published documentation, the platform expects a response within a few seconds and will move on regardless of what happens downstream. There is no built-in retry queue. If your receiver is down, the signal is gone.

That property drives most of the architectural decisions in this space: single-point-of-failure at the receiver, no replay, no acknowledgment. Every serious relay adds its own idempotency and retry logic because TradingView deliberately does not.

Plan requirements and the alert caps that surprise people

Webhook alerts are a paid feature. The Essential plan is the minimum tier that exposes the webhook URL field in the alert dialog. Below that is the free tier, which caps active alerts at a handful and does not offer webhooks at all.

The practical trap is alert expiry. Essential and Plus alerts stop firing roughly two months after creation. You have to open each one and extend it, or it silently goes dark. Premium and Ultimate allow open-ended alerts that run until you delete them. If you are building a live system off a Plus subscription, put “refresh TradingView alerts” on your calendar as a recurring task or plan to upgrade before the first expiry wave.

Exact alert caps shift occasionally as TradingView adjusts tiers. Confirm the current number on TradingView’s pricing page before committing to a plan that barely fits your alert count.

The five-step setup, written as checklist, not marketing

Every tutorial presents this as five to eight steps. The steps are the same everywhere; the gotchas vary by broker and relay.

1. Enable two-factor authentication on the TradingView account. TradingView requires 2FA before it will let you save a webhook URL. No 2FA, no webhook. This is a hard requirement on TradingView’s side.
2. Generate or receive a webhook URL from the destination service. For a managed relay, log into your platform dashboard and copy the unique URL assigned to your strategy or account. For a self-hosted script, this is the public HTTPS endpoint of your Flask/FastAPI/Lambda function. The URL must be HTTPS — TradingView rejects plain HTTP.
3. Write the alert message as JSON, not prose. Plain-text messages work for simple relays but restrict what you can send. JSON lets you parameterize ticker, side, quantity, order type, stop, target, and routing hints. Most middleware expects a specific JSON shape; copy their template rather than inventing one.
4. Create the alert, paste the webhook URL in the Notifications tab, and paste the JSON in the Message field. Decide whether it fires on bar close (stable, signal confirmed) or intrabar (faster, risks whipsaws). For entries driven by Pine Script strategy.entry() calls, bar close is the safer default unless your strategy explicitly depends on intrabar signals.
5. Test with a dry-run order or a paper account before touching real capital. Manual “Test” buttons in TradingView only send the message once. A better test is to trigger the underlying strategy condition on a paper account, confirm the full path fires, and verify the broker accepts the order format.

The step that eats the most time is step 3. Every relay has opinions about field names. Ontology Trading, TradersPost, PineConnector, Alertatron, WunderTrading — all parse slightly different JSON. Stick to the documented schema for your chosen receiver and use Pine Script string placeholders ({{ticker}}, {{close}}, {{strategy.order.action}}) to dynamically fill it.

A minimal JSON payload that works for most relays

A reasonable baseline payload includes the ticker, action, quantity, and a secret that the receiver can check before executing. Here is the shape most managed relays accept with minor field renames:

{
  "ticker": "{{ticker}}",
  "action": "{{strategy.order.action}}",
  "quantity": 100,
  "order_type": "market",
  "time_in_force": "day",
  "secret": "your-shared-secret-here"
}

TradingView substitutes the curly-brace placeholders at alert time with the real symbol and the direction (“buy” or “sell”) produced by the strategy. The secret field is checked by the receiver to reject unauthenticated calls — anyone who guesses your webhook URL could otherwise fire orders into your account.

If you need sizing in dollars rather than shares, most relays accept a quantity_type field with values like dollar_amount, percent_of_equity, or risk_percent. The defaults vary; read the relay’s docs before assuming. A common failure is a test alert firing 100 contracts of an options symbol when the trader meant 100 dollars.

Receiver options, ranked by operational overhead

The question “how do I automate TradingView alerts” really collapses into “which receiver do I want?” There are four choices, each with a different cost curve.

The managed relay tier is where the market has settled for most retail algo traders because it amortizes three problems at once: broker API maintenance (the relay keeps up with API changes so you don’t), retry/idempotency logic, and order translation (position sizing, PDT checks, bracket orders). If you are running a single strategy on a single broker, broker-native can be simpler. Past two strategies or two brokers, a managed relay usually wins on operational hours saved.

Prove-It: the latency and reliability numbers you actually care about

Every relay claims to be “lightning fast.” What matters in practice is end-to-end latency from bar close to broker fill confirmation. Published numbers from the major relays cluster in the 250–800 millisecond range for US equities during regular hours, with long-tail excursions above 2 seconds when broker APIs throttle or queue.

A useful rule: if your strategy’s edge disappears with 1 second of added latency, stop trying to automate it through TradingView webhooks. TradingView’s own delivery latency is not deterministic, and stacking a retail broker API on top adds variance. Scalping strategies with sub-second edges belong on a co-located stack, not on a webhook chain.

For swing and intraday strategies with 5-minute-or-longer bars, webhook latency is almost always acceptable. The limiting factor is broker API behavior during open-session chaos, not TradingView.

Two prove-it facts most relay tutorials leave out:

• TradingView’s webhook timeout is short. The platform expects your receiver to accept the request within a few seconds. If the receiver blocks on a slow broker API call, TradingView gives up and logs the alert as sent — while nothing actually executed. Good relays respond immediately and queue the broker call in the background.
• Duplicate fires are the rule, not the exception. A single bar can produce multiple alert events if your Pine condition flickers. Production-grade receivers track an idempotency key derived from the bar timestamp + ticker + action so a flickering condition doesn’t place three orders.

Original data experiment: the 90-day alert-chain audit

In a review of publicly documented incidents across r/algotrading, TradingView community posts, and relay-vendor postmortems over a rolling 90-day window in early 2026, the most common failure modes for webhook-driven automation break down roughly as follows:

The pattern is consistent: TradingView’s side rarely breaks. The failure almost always sits in the receiver or in the glue between receiver and broker. That’s why the “which relay” question usually matters more than the “which TradingView plan” question once you’re past the Essential tier.

Break-even math: DIY script vs. managed relay

The self-hosted appeal is obvious: $5/month for a small VPS or pennies on Lambda, versus $30–$80/month for a managed relay. The break-even arithmetic looks different once you include time.

A reasonable first build — Flask app, broker SDK wiring, basic idempotency, secret verification, logging — takes a competent developer 8–15 hours. At a self-imposed hourly value of $50, that’s $400–$750 in opportunity cost before a single trade fires. Post-launch you own the patching: broker API changes, TLS certificate renewals, VPS reboots. Annualized, most DIY operators spend another 15–30 hours per year keeping the system alive.

Break-even for a $40/month managed relay: roughly 14–18 months of platform fees before the DIY option starts saving money in pure dollars — and only if your time is worth zero or you enjoy the maintenance. The honest call is that managed relays win for anyone whose primary work is trading, not infrastructure.

The exception: traders with unusual broker or exchange requirements that no managed relay supports, or those running multi-asset strategies that need custom routing logic. In that scenario, self-hosted is not a choice; it’s a requirement.

Security basics people underrate

Three mistakes account for most “someone placed orders in my account” stories:

1. Posting the webhook URL publicly. The URL is a credential. If it’s on GitHub, Discord, or a screenshot, assume it’s compromised. Rotate it.
2. Skipping the shared-secret check. Any receiver should reject POSTs that don’t include the expected secret value. Managed relays do this by default; self-hosted scripts often don’t unless the developer added it.
3. Storing broker API keys with full withdrawal permissions. Use trade-only keys wherever the broker supports permission scoping. Most brokers do. It limits blast radius if the relay or your script is ever compromised.

Not for you: when automating TradingView alerts is the wrong move

Honest no-go scenarios:

• Your “strategy” is still being tuned. Automating an unfinished rule set just lets it lose money faster. Paper-trade manually until the edge stabilizes.
• Sub-second scalping on US equities. TradingView-webhook latency variance plus retail broker API queuing can easily eat 1–2 seconds. If your edge lives in that window, you need a co-located, direct-API setup, not a webhook chain.
• You trade one discretionary idea a week. If you enter trades based on judgment calls and only a few times per week, a webhook pipeline adds complexity with no benefit. Click the button.
• Your broker has no API and no relay supports it. Some regional brokers still lack any programmable interface. Automating through TradingView is impossible regardless of which relay you pick.
• Pattern day trader risk is not handled. If your strategy can fire more than three day-trades in five business days on a sub-$25k account, you need a receiver that blocks the fourth day-trade. Not all do. This is where a mature relay earns its fee.

How Ontology Trading fits the stack

Ontology Trading sits in the managed-relay tier with a distinguishing feature: an AI strategy builder that drafts the Pine Script and JSON payload together, so the alert’s message field comes pre-shaped to Ontology’s receiver. The relay forwards to Interactive Brokers, Alpaca, Webull, Tastytrade, Coinbase, Kraken, and other supported venues. For traders who would otherwise spend an evening writing Pine Script and a second evening writing a compatible webhook payload, the combined flow removes the boilerplate.

Ontology is not the only option in this category — TradersPost, PineConnector, Alertatron, and Capitalise.ai each serve overlapping but distinct audiences. A practical comparison is in our platform guides, including detailed breakdowns of the TradersPost alternative landscape and the PineConnector alternative market for MetaTrader-free workflows. Pick by broker coverage first, feature depth second, and pricing third.

Frequently asked questions

Do I need to know Pine Script to automate TradingView alerts?

No, but it helps. A simple price-cross alert can be automated with zero code: pick the indicator, set the condition, paste the webhook URL. For anything strategy-like (entries, exits, sizing, stops), Pine Script unlocks the placeholder variables that make the JSON dynamic. AI strategy builders like Ontology’s can generate the Pine code for you.

Can I automate TradingView alerts with a free account?

No. The webhook URL field is gated behind a paid plan. Essential is the minimum tier that shows it in the alert dialog. There are community workarounds that poll TradingView’s chart for signals, but they are fragile and violate the terms of service.

How fast is a TradingView webhook in real trading?

End-to-end from bar close to broker fill confirmation typically runs 250–800 milliseconds on US equities, with occasional excursions past 2 seconds when broker APIs throttle. Fine for swing and intraday strategies. Not fine for sub-second scalping.

What happens if the receiving webhook server is down?

The signal is lost. TradingView does not retry. This is why managed relays advertise uptime SLAs and why self-hosted operators need monitoring. A missed signal on an entry is annoying; a missed signal on an exit can be expensive.

Can one TradingView alert send orders to multiple brokers?

Not natively. The alert posts to one URL. To fan out to multiple brokers, your receiver needs to do the duplication — most managed relays support multi-account routing where a single incoming alert produces orders at two or more connected broker accounts.

Is it safe to put my secret in the TradingView message field?

Safe enough if the account has 2FA on, the webhook URL uses HTTPS, and the secret is unique per strategy (so a leak only compromises one alert). Rotate the secret if you ever suspect exposure. Never reuse broker login passwords as webhook secrets.

Why did my alert fire but no trade was placed?

Most common causes in order of frequency: JSON syntax error, wrong secret, relay or broker rejected the order for buying-power or PDT reasons, alert expired silently, or the receiver was down during the POST window. Check the relay’s log first — every mature platform exposes a per-alert audit trail.

Do alerts keep working if I close my browser?

Yes. TradingView alerts run server-side. Once saved, they fire independent of whether you have a browser tab open. This is different from on-chart Pine strategies, which only run in the browser — the alert is the server-side bridge that makes strategy automation possible.

Next step

The practical sequence is: upgrade to Essential or Plus if you are not already there, enable 2FA, decide between managed relay and self-hosted, set up a paper account at your broker, and run a week of paper trades end-to-end before risking real capital. If you want the entire chain in one platform — strategy draft, Pine code, webhook payload, broker routing — see the Ontology Trading AI strategy builder for the combined workflow.

More depth on adjacent topics: TradingView webhook setup guide, TradingView alert webhook JSON reference, and Pine Script to live trades.