TradingView Fibonacci Drawing Alerts —
Two Traps for Webhook Users

You drew a Fibonacci retracement on the chart and you're waiting for the 0.618 to get hit. Until recently, sending that level to a webhook meant one of two things: manually copy the current 0.618 price onto a horizontal-line alert, or write a bit of Pine that computes the level for you. In a May post, TradingView announced that the middle step is gone — alerts can now sit directly on Fibonacci drawings themselves (source: tradingview.com/blog/en/alerts-on-fibonacci-drawings-58692).

This piece is about that new path — TradingView Fibonacci alert webhook — and the two things the official announcement doesn't spell out.

This post won't rehash the marketing copy from that blog — for the GIFs, go read the original. It only answers the two things that actually matter to webhook users:

• Where the official docs stop, and what isn't said
• How "drawing moves = alert trigger moves with it" can quietly turn your automated orders into something else entirely

What This New Feature Actually Covers

Two Drawings the Docs Explicitly Support

TradingView's blog only names two drawings: Fib Retracement and Trend-Based Fib Extension. The other tools in the Fibonacci family — Fib Channel, Fib Speed Resistance Fan, Fib Circles, Fib Time Zones — aren't mentioned in the blog, and the alerts section in the official help docs only appears under those first two.

• Fib Retracement: alerts section is in the Retracement help doc
• Trend-Based Fib Extension: alerts section is in the Extension help doc
• Other Fib family tools: no alerts section in the docs today. Click through in the UI yourself before you rely on it.

Saying "every Fib tool supports alerts" is a gut-feel extrapolation. Before you build strategy on it, click through the UI yourself. What follows is only the part we can actually verify.

The Creation Steps Are the Same as Before

Three steps, identical to how you already add alerts to indicators:

1. Draw the Fib retracement or Trend-Based Fib Extension on the chart
2. Right-click the drawing → Add alert; or hover over the drawing and use the floating menu to open the alert dialog
3. In the Condition field of the dialog, pick the level and the trigger type you want

The real difference is in step three — the alert dialog now has two new groups of condition options, and that's where the value of this feature actually lives.

Two Sets of Conditions: "A Single Level" vs. "Between Two Levels"

The Original Wording

The blog splits conditions into two explicit groups. Verbatim:

• For a single level: 「Crossing, Crossing Up, Crossing Down, Greater Than, or Less Than」
• For the space between two levels: 「Entering Channel, Exiting Channel, Inside Channel, or Outside Channel」

For webhook users, this matters more than it looks — with horizontal-line alerts, you could only set crossing on a single price.

The channel conditions on Fib drawings let you express an interval event like "price entered the zone between 0.5 and 0.618" in a single alert, without doing the arithmetic yourself. What used to be an if statement in Pine plus two series comparisons is now a dropdown.

How It Differs from a Horizontal-Line Alert

From an automation standpoint, the most valuable row is the second-to-last — what used to require Pine to "track a dynamic level" is now one drag of a drawing. That's also exactly the first trap this post is about.

"The Alert Moves with the Drawing" — Where the Docs Stop

The Only Sentence in the Original

The blog has exactly one sentence describing the drag behavior:

Plain read — the alert moves with the tool whenever you reposition it or change its settings.

Why This Matters for Automation

The point isn't that the docs are vague — it's that "dragging" has never been a safe action in an automated trading architecture. Under horizontal-line alerts, your trigger condition was a hardcoded price; moving a drawing only affected what you saw on your own screen, not the trigger logic. Now the drawing and the trigger are the same object, and one mis-click or one demonstration drag during a code review is enough to materially change the trigger price.

Trap #1: The Moment You Drag, You May Already Be Triggering Something Else

Compared to the Horizontal-Line Era

Say you have a webhook strategy: go long when 0.618 gets crossed downward. In the horizontal-line era, the alert was bound to a concrete price (say 62,300); after you moved the Fib drawing to a new swing, the alert condition was still the old 62,300, unless you manually changed it.

What you care about today is the new swing's 0.618 (maybe 63,850), but the alert is firing on the old value. You'll fail to notice that "the trigger price doesn't match where the drawing sits", because your visual attention is on the new line — that's broken, but at least it's visibly broken.

Now, with Fib Drawing Alerts

Fib drawing alerts reverse the situation: the drawing moves, and the trigger moves with it. For a discretionary trader that's a feature; for an automated trader it's extra responsibility. Your order server has no way of knowing that "this alert's trigger price was 62,300 yesterday and is 63,850 today" — all it sees is "this alert fired".

If your position size or risk logic is computed off a specific absolute price (as covered in webhook position sizing — this is how a lot of people actually build it), then after you drag a Fib, the signal your webhook sends and the numbers your downstream logic assumes silently stop matching. Nothing warns you.

What to Do Now

Four things, in order of importance:

• Keep a Fib alert register: for every Fib drawing that has an alert on it, record the creation time and the current level price, then diff after any change
• Group Fib alerts for the same strategy in one chart layout: retracements and extensions together, so you review them in a single pass. Scattered across multiple layouts, the diffs get too messy to follow
• After any change, manually disable and re-enable the alert: TradingView doesn't promise the condition re-evaluates on drag, so the safe reset is to toggle it off and on
• Include {{plot}} or {{close}} in the payload: your own logs will show the actual price the alert fired at, giving you something to diff against later

Trap #2: Whether the log-scale Box Is Ticked Changes the Level Substantially

Two Ways to Compute a Level

This isn't the same issue as the alert one, but it decides what price your alert fires at, so it belongs here. Fibonacci levels can be computed two ways:

• Linear: proportional split of the raw "price difference"
• Log scale: proportional split of the "log-price difference"

Why Crypto Needs Log Scale

Crypto is volatile enough that 5%–10% single-day moves are routine, and on a log chart a 0.618 computed linearly is off. The Fib Retracement doc says so explicitly:

There are two practical consequences.

Two Practical Consequences

One, on the same swing and the same chart, a 0.618 computed with log scale on and one with it off are different prices. Your alert is bound to whichever level was calculated at the moment you set it up — whether that alert updates when you change the setting later, the official docs don't say.

Two, if some of your alerts have the box ticked and others don't, you'll look at them and think "they're all 0.618", when in reality the trigger prices can be $100 apart. That's an inconsistency in your own setup, not a TradingView bug, and nothing will flag it for you.

Four Things the Docs Don't Spell Out for Fibonacci Alert Webhooks

Refusing to Answer Beats Answering Wrong

As of 2026-07-31, the following items are not covered anywhere verifiable in the TradingView blog or support docs. Don't trust other tutorials that state them with certainty — go verify on the official pages yourself.

• Which paid plans: neither the blog nor the four related docs mention any plan tier; alerts do have per-account quotas, but whether Fib alerts fall under the same quota isn't explicitly stated either
• Mobile app support: the blog describes Supercharts / desktop only
• Other Fib tools (Channel, Speed Resistance Fan, Circles, Time Zones): no alerts section in the docs today. Right-clicking in the UI may or may not surface Add alert
• Whether all legacy horizontal-line alerts should be migrated: the docs don't mark horizontal-line alerts as deprecated. The two can coexist.

Why "Not Stated" and "Not Supported" Are Different

Each of those items is "not stated in the original", not "stated as unsupported". Big difference: unsupported is a permanent fact, whereas not-stated could mean they haven't published yet, or that they default to all alerts' general rules, or that they haven't decided themselves. Which interpretation you bet on is your call, not ours.

What You Can Do Today

If You Already Have a Webhook Running

If you've got a TradingView webhook live already: spend five minutes checking one thing — whether any of your current alerts are the "drawing + manually typed price" combo. Those are the best candidates to migrate to Fib drawing alerts (assuming you've internalized the first trap above).

The step-by-step for creating alerts in TradingView Webhook Tutorial doesn't change — the condition dropdown just has Fib drawings as one more option now.

If You Don't Have a Webhook Running Yet

If you don't have a webhook running yet: Fib drawing alerts don't make "get the receiving server built first" any less important — they just add one more type of signal source. Everything the downstream needs to do — your own API key, dry-run, alert state persistence — is still on the list.

FAQ

Five questions that cover most of what gets asked about this post:

• After I drag the drawing, will the webhook immediately fire with the new position?
• Is this feature on every TradingView plan?
• What about the other Fib family tools?
• Should I migrate all my old Pine strategies?
• Does TVSBot handle Fib drawing alerts any differently on the execution side?

Signal Source and Plan

Do Old Pine Strategies Need to Change

Does the Execution Side Treat Them Differently

Related Posts