TradingView Watchlist Alerts Now Support Extended Hours
The trigger window for your cross-session automated orders just changed

You've been sending webhook orders off TradingView watchlist alerts for a while, and up until now they only fired during regular US hours — your execution server was busy from 9:30 to 16:00 ET and quiet the rest of the day. On July 2 that changed: TradingView added extended-hours support to watchlist alerts, and the whole thing is one dropdown deep. Create a new alert, flip the Session selector at the bottom to Extended, and now the webhook fires at 04:00 pre-market and 20:00 after-hours as well.

What nobody told you up front: TradingView didn't change the payload fields, didn't change the trigger-frequency semantics, and didn't touch the 3-second receiver timeout. All they did was extend the Session switch to watchlist alerts — a single dropdown — but that switch reaches into a segment of the day your execution stack has probably never been stress-tested against.

This piece doesn't argue about whether extended-hours trading is worth running — that's a strategy call, not a mechanism question, and we haven't done any comparative live tests. What it does do is three things: quote the four rules TradingView's own 2026-07-02 blog spells out in black and white, unpack the three ways this actually hits webhook automation, and hand you a checklist you can walk through in the UI yourself.

First, Scope: This Change Only Touches Watchlist Alerts

On TradingView, "alert" isn't one thing — it's three separate entry points people mix together. There's the one you build from the clock icon on the top-right of a chart (chart alert), the one from the bell on top of a watchlist (watchlist alert), and the one your Pine script fires via alert() or alertcondition() (script alert). Each of the three has its own Session semantics, and this update only moves one of them.

Put another way: if your strategy runs conditions inside a Pine script and fires a webhook, this update doesn't hit you directly. What it does move is "point a watchlist at a whole basket of stocks/ETFs and fire when any of them meets a condition" — the pattern people use for gap-up alerts, earnings breakout scans, that kind of short-term US equity screening.

How much this matters to you depends entirely on whether you have a watchlist alert like that running. If you don't, this is informational. If you do, it's a UI check you need to do. The gap between "doesn't affect me" and "my strategy behaves completely differently now" has no middle ground.

The Four Rules TradingView Actually Wrote Down

The four items below all come, unedited, from TradingView's 2026-07-02 blog post — you can cross-check them against the original at Extended hours support for watchlist alerts is here. Nothing added.

Three Ways Extended Hours Actually Hit Webhook Automation

Impact 1: Your Execution Server Is Busy for a Lot Longer

Your webhook receiver used to be busy for 09:30–16:00 ET — roughly 6.5 hours a day. Flip to Extended and you add 04:00–09:30 pre-market (5.5 hours) in front and 16:00–20:00 after-hours (4 hours) behind, for a total of 16 hours a day — about 2.5× the original.

How much this actually matters depends on whether your receiver has ever been stress-tested during the off-session window — the log monitors that run at night, the database maintenance that runs mid-day, the cron jobs you scheduled yourself; any of them may happen to run in pre-market or after-hours and now collide with fresh incoming webhooks. Your server doesn't know 04:30 and 09:35 are different worlds — you have to draw that line in your architecture yourself.

Impact 2: Your Broker May Not Follow You There

Even if TradingView delivers the webhook, your next hop is a broker or exchange API — and that side may not support extended-hours orders. Among common US brokers, pre-market and after-hours trading usually requires enabling extended-hours order permissions separately, and often only accepts limit orders, not market orders. This is a broker-side rule, unrelated to the TradingView update, but if you haven't verified it up front, your webhook will just get one silent rejection after another — and often the rejection isn't loud, it's just quietly rejected.

For the boundary conditions here, see Which Exchanges Actually Support TradingView Webhook Signals? An Honest 2026 List — that piece covers crypto exchanges, but the pattern for US brokers is identical: verify whether the API supports cross-session orders before deciding whether to flip your alert's Session dropdown to Extended.

Impact 3: The Gap Between Backtest and Live Widens

When you run a Pine strategy backtest on TradingView, strategy uses the data shown on the chart — which, by default, doesn't include pre-market or after-hours. But the moment a scanning watchlist alert flips to Extended, its live triggers fire on pre- and after-market data — data your backtest has never seen. This is a textbook backtest/live data-source mismatch.

Take a hypothetical to make the gap concrete (numbers here are for illustration, not measured): you wrote a 5-minute breakout above the intraday VWAP watchlist alert to catch gap-ups. The backtest on regular-session data looks fine, so you flip Session to Extended. In live trading, the 04:35 5-minute bar in pre-market has meaningfully lower volume and a much wider bid-ask spread; the same "VWAP breakout" signal firing in that window can eat the entire edge on slippage alone — and that damage never shows up in the backtest, because the backtest timeline doesn't contain a 04:35 bar to compare against in the first place.

Whether to turn Extended on is not a question with a fixed answer. But you at least need to be aware that the moment you flip that dropdown, your live strategy is decoupled from its backtest basis. For a fuller treatment of cross-session risk sizing, see ATR Position Sizing: A Complete Guide — realized volatility in pre- and after-market is typically not the same as regular session, and running the same parameters across both is a hazard.

Three Steps: How to Turn It On, How to Turn It Off

Here's the flow from the official blog post (if you want to try it, or want to confirm you haven't accidentally flipped one):

Bell icon at the top of the watchlist → Create alert
          → Choose Watchlist (in the Symbol field)
          → Define your technical condition (e.g., Price Moving Up)
          → Parameters block at the bottom → Session dropdown
          → Switch to Extended
        Save

To turn it back off, flip that same Session dropdown to Regular and save — old alerts have to be edited one at a time; there's no bulk switch for "change all my alerts". Which is why the cost of turning it on is a few seconds and the cost of turning it off is dozens of manual clicks — an asymmetry worth internalizing before you touch it.

Should You Turn It On? Answer These Four First

• Has your execution server ever been stress-tested during pre-market or after-hours? If not, leave it off until you've run the test.
• Does your broker/exchange API support pre-market and after-hours order placement? Only limit orders, or market orders too?
• Does your strategy's backtest include extended-hours data? If not, flipping the switch live is a bet on data you've never tested against.
• Does your position-sizing (strategy.percent_of_equity and the like) account for the fact that off-hours liquidity is thin and slippage can run three to five times normal-session levels? If you haven't worked that math, leave it off.

If any one of those four is unanswered, leave Session on Regular — finding the answer to that specific question is safer than flipping every alert at once. Off-hours liquidity in US equities is typically an order of magnitude thinner than the regular session — that's the well-known character of the market rather than a number we measured, but it's enough to make "use the same parameters, just wider hours" a distinct risk decision on its own.

Honest Section: Three Things the Docs Don't Cover

Below are questions we derived from reading the official blog — TradingView hasn't publicly answered any of these three, and we're listing them so that, before you touch the switch, you know what you'd need to verify yourself:

All three of these you have to test yourself — set up a low-cost verification alert (with a condition loose enough to guarantee it fires and a webhook endpoint that only logs, not trades), run it for a week, look at the actual trigger timestamps, the payload contents, and whether you're getting rate-limited. Verification runs like this are basic hygiene in any failover design for automated trading — don't use TVSBot's dry-run for it and don't use a real book — the cheapest way is to point a free request-bin service at it and just record. For a walk-through, see What Happens If TradingView or Your Exchange Goes Down? Failover Design for Automated Strategies and its self-verification section.

FAQ