TradingView Automation: Executing Alerts End to End

Your alert fired at 14:32. The chart shows the entry. Your account shows nothing.

Somewhere between those two facts sit four separate systems, and any one of them can fail without telling you. TradingView thinks it did its job. Your bridge may never have heard about it. Your broker certainly didn't.

Automating a TradingView strategy means connecting four things: a Pine script that produces a signal, an alert that fires on it, a webhook that carries it out of TradingView, and a bridge that turns the message into an order at your broker or exchange. TradingView itself never places the trade. It sends one HTTP request and stops caring.

That last sentence is the one most setups are built without understanding, and it explains most of what goes wrong.

What actually happens between an alert firing and an order existing?

Five stages, each owned by a different system.

1. Pine evaluates. Your script's condition becomes true on a bar.

2. TradingView's alert engine fires. It builds the message you wrote and hands it to the webhook sender.

3. A single HTTP POST leaves TradingView. One request, to one URL, with your message as the body.

4. A bridge receives it. It parses the message, works out size and symbol, and calls your broker or exchange.

5. The venue accepts or rejects. An order exists, or an error does.

Nothing in that chain reports backwards. Stage 5 doesn't tell stage 3 what happened. TradingView's alert log will show the webhook was delivered, and that's the outer limit of what it knows — delivered means a server answered, not that a trade exists. A bridge can accept a message, fail to place the order, and TradingView will still show a green delivery.

That gap between "delivered" and "filled" is where automated setups quietly stop working. Everything below is about the specific places it opens up.

Why doesn't TradingView just place the trade?

For most venues it can't. TradingView has direct broker integrations for a set of supported brokers, For everything outside that set, which includes most MT5 brokers and most crypto exchanges, the webhook is the only way out. It's an outbound message, not a trading connection.

That has a consequence worth stating plainly: the webhook is a notification system that happens to be pointed at trading infrastructure. It was built to tell things that something happened. Retry on failure, confirmation of receipt, knowledge of whether the thing on the other end did anything: every guarantee you want from an order routing system has to come from the bridge, because the transport doesn't provide any of them.

What does TradingView actually send, and under what rules?

One HTTP POST containing your alert message as the request body. The constraints are published and most of them are unforgiving.

Ports 80 and 443 only. Any other port in the URL is rejected outright, not retried. This catches people running a receiver on 8080 during testing.

Three seconds, total. If the receiving server takes longer than three seconds to respond, TradingView cancels the request. That budget includes DNS resolution, so a slow-resolving domain on a cheap VPS spends part of your window before your code runs at all. The correct pattern for a self-built receiver is to answer immediately and process afterwards, never to place the order and then respond.

No IPv6. The receiving server needs an IPv4 address.

Content type is decided by your message, not by you. If the alert message parses as valid JSON, TradingView sends it as application/json. If it doesn't, it goes as text/plain. A missing brace turns a JSON payload into plain text, and endpoints that only accept JSON reject it. The alert looks fine. The message looks fine. The content-type header is what changed.

Retries exist, but only for one failure class. A 5xx response from your endpoint gets retried up to three times at five-second intervals, so four attempts in total. A timeout gets nothing. A 4xx gets nothing. A redirect is treated as a failure. Almost every guide gets this wrong in both directions. The ones saying TradingView never retries are wrong. The ones saying it retries on failure are more wrong, because the failure you'll actually hit is the timeout, and that one is gone forever.

The practical reading: your bridge returning a fast 200 is the single most important thing in the chain, and a bridge that returns 200 before it has done anything is both correct behaviour and the reason a delivered webhook proves nothing.

TradingView does give you a Webhook status column in the alert log. Check it. It's the only place the transport tells you anything, and it's the first thing to look at when the chart and the account disagree.

What goes in the alert message?

Whatever your bridge expects, and nothing else.

The message is a contract between you and one specific receiver. Some bridges want a line of comma-separated values. Others want JSON with named fields. The formats aren't compatible and there's no standard, which is why moving between vendors means rewriting every alert you have rather than repointing a URL. The cross-vendor mapping is a subject of its own.

What's common to all of them is the choice between hardcoding a value and letting TradingView fill it in. Placeholders in double braces get substituted at fire time: the ticker, the close price, the timeframe, and for strategy scripts the order action, contracts and position size the strategy believes it just took.

Use them sparingly, and here's the rule I'd apply. Anything the bridge needs to identify what to trade should be hardcoded in the alert, because a placeholder that resolves to the chart's symbol will hand your MT5 bridge a string your broker has never heard of. Anything describing what just happened is fine as a placeholder, because you want the actual value rather than your guess at it.

The specific trap is price. A placeholder resolves to the value at the moment the alert fired, and by the time the order reaches the venue that price is history. Sending it as a limit price is how you get an order that sits unfilled while the move happens without you. If you want a limit, calculate the offset at the bridge, where it can be applied against a current quote.

Keep the message minimal. Every field is a thing that can be malformed, and a single missing brace turns the whole payload into plain text.

Who else can post to your webhook URL?

Anyone who has it. That's worth sitting with for a second.

The webhook URL is the credential. There's no username, no password, and no signature on the transport itself. If your endpoint accepts a message and acts on it, then any request arriving at that URL in the right shape places a trade. The URL is not a location, it's a bearer token that happens to look like a link.

Three consequences follow.

Never put it in a screenshot. This is the single most common way these leak, and it happens constantly in support threads and YouTube tutorials where someone films their alert configuration. Blur the whole field, not the last few characters.

Allowlist the source. TradingView publishes the small set of IP addresses its webhooks originate from, all in one AWS region. Restricting your endpoint to those addresses means a leaked URL is close to useless to anyone who isn't spoofing from inside that range. Take the current addresses from TradingView's own documentation rather than from any blog, this one included, because they can change and a stale allowlist fails closed and silently.

Put a shared secret in the message body. If your bridge supports it, include a token as a field and have the receiver reject anything without it. That gives you something you can rotate without rebuilding the endpoint, which matters because rotating a URL means editing every alert you have.

Hosted platforms generally handle the first two for you and give you a per-account endpoint you can regenerate. A self-built receiver on a VPS handles exactly as much of this as you wrote, which for most people's first attempt is none of it.

Does a strategy alert mean what you think it means?

This is where the most expensive misunderstanding lives, and it has nothing to do with plumbing.

Pine has two relevant script types. An indicator script calculates and draws. A strategy script also maintains a simulated position: it records entries and exits, tracks a hypothetical equity curve, and produces the numbers you see in the Strategy Tester.

When a strategy script fires an alert, that alert is generated from the simulated position. TradingView filled the order in its own model. Whether anything happened at your broker is not something the strategy knows or checks, and the Strategy Tester will keep reporting a position it believes you hold long after your real one was rejected for invalid volume.

So the two never reconcile. They aren't connected. And the divergence compounds: a strategy that missed its entry will still fire the matching exit, which arrives at your bridge as a close instruction for a position that doesn't exist.

What that means in practice is that your bridge's behaviour on an unmatched exit is a real configuration decision, not an edge case. Some ignore it. Some send a close for zero volume and error. Some open a position in the opposite direction. Find out which yours does before it happens, because the first time this fires you want it to be boring.

Alert frequency is the related trap. An alert set to trigger Once Per Bar fires while the bar is still forming, on a condition that can un-happen before the bar closes. Once Per Bar Close fires on confirmed data. The difference changes which trades you take, not just when. It also interacts badly with any indicator that repaints. That's its own subject and it gets its own article.

Where does position state actually live?

In three places, and they never automatically agree.

Only the third row is real. The other two are models of it.

Most automation failures I've watched are a divergence between rows that nobody noticed for days. The strategy is flat and the account isn't. The bridge thinks it has one position open and the account has two, because a retry landed. Nothing errors, because from each system's own point of view nothing went wrong.

The discipline that prevents it is unglamorous: reconcile against the venue, not against the chart. Your broker's position list is the answer to "am I in this trade." The Strategy Tester is the answer to "what would this strategy have done," which is a different question and always has been.

What kind of bridge do you need?

Four architectural shapes exist. Vendors differ inside each shape, but the shape decides more about your setup than the brand does.

The trade-off is the same in every row. The closer the logic sits to your terminal, the less it depends on a vendor being alive, and the less it can ever see beyond that one terminal. The further out it sits, the more it can coordinate across accounts and venues, and the more it needs a live connection to act.

The fourth row has a split worth reading carefully. A crypto exchange account connects over the internet with nothing on your machine, so it keeps running with your computer off. MT5 has no equivalent, so even a fully server-side platform still needs a terminal awake somewhere to reach your broker. Same product, different answer depending on the venue.

Two things follow that catch people out. A same-machine architecture means your trading laptop closing its lid is an outage. And an MT5-only bridge means a crypto account isn't part of the same system, no matter what the marketing page groups together.

Vectorhelm is the fourth shape. Alerts arrive at our endpoint, the logic runs on our side, and connectors carry instructions to MT5 brokers and crypto exchanges. The honest counterweight is in that same row of the table: it needs a live connection to act, which is a real constraint and one worth reading about before choosing an architecture rather than after.

What does your TradingView plan gate?

Webhooks are a paid feature. The free tier gives you a small number of price alerts, no technical alerts, and no webhook delivery at all. A Pine script alert of any kind, let alone an automated one, needs a paid plan before anything else in this article applies.

Above that, the two things that matter for automation are how many alerts you can hold active at once and whether they expire. Lower paid tiers expire alerts after roughly two months; the top tiers don't. An expired alert doesn't error. It stops existing, and your strategy goes quiet in a way that looks exactly like a market with no setups.

Exact counts and prices move, and they changed in April 2026, so check the current numbers rather than trusting any table on any blog, including a table on this one. The tier detail gets its own page.

What breaks, roughly in order

Ranked by how often I've seen each one actually be the cause:

1. The alert expired, or the alert cap was silently reached

2. The message isn't valid JSON, so it arrived as text/plain and got rejected

3. The symbol on the chart doesn't map to the symbol at the broker

4. Volume rounding: the calculated size isn't a legal multiple of the venue's step

5. The receiver took longer than three seconds and the request was cancelled

6. The alert is set to a frequency that doesn't match what the strategy intended

7. Something on the machine died: the VPS rebooted, the terminal closed, the app was never restarted

Notice how few of those are exotic. The top four are configuration, and three of the four produce no visible error anywhere in TradingView. Each of these gets a page of its own, because "why isn't my alert firing" and "why did my order get rejected for invalid volume" are different problems with different fixes and people search for them separately.

What arrives at the venue isn't what the alert said

An alert says "buy." An order says "buy 0.37 lots of EURUSD.raw at market." Everything between those two sentences is the bridge's arithmetic, and it's where the chain most often produces something legal but wrong.

Position size has to be derived from something: a fixed lot, a percentage of equity, or a risk-per-trade calculation against the stop distance. Then it has to be rounded to the venue's volume step and clamped to its minimum and maximum. Symbols have to be mapped, because the EURUSD on your chart and the EURUSD.raw or EURUSD_i at your broker are different strings. Both of these have their own failure signatures and their own articles.

The point for this page is narrower: an automated setup that works on paper and fails in practice usually fails here, in translation, not in the strategy.

The honest limitation

Automation removes hesitation, which is the point, and it removes the pause where you would have noticed something was wrong, which is the cost.

A discretionary trader whose feed breaks sees a flat chart. An automated trader whose bridge breaks sees nothing at all, because absence of trades looks identical to absence of signals. That's the failure mode specific to this whole category, and it's not solved by a better bridge. It's solved by checking, on a schedule, that the thing is alive — and by treating a quiet week as a question rather than as a market condition.

If you won't do that, automation is a worse fit for you than manual execution, and it's better to know that now than after a month of silence.

Where to start

Build it in this order, and don't skip forward.

Get a signal out of TradingView before you connect anything to money. Point a webhook at any endpoint that shows you what it received. Confirm the alert fires when you expect, that the body arrives as JSON, and that the content type is what you think.

Then connect one venue, one strategy, on a demo or sandbox account. Not three strategies. One, until you've seen it place an entry, take an exit, and handle a rejection.

Then decide where your limits live. Before you go live, not after. An automated strategy with no account-level ceiling above it can spend a full day's budget in the time it takes to notice, which is the failure this whole category is best at producing.

Then add the second strategy.

We're building the fourth-shape version of this: alerts in, risk enforced, orders out across MT5 and crypto, with limits at strategy and account level. It isn't open yet. Early access is here if you want it when it is.

Vectorhelm is execution software. It runs the rules you define on accounts you own and control. Nothing here is trading advice, and no automation setup prevents losses.