TradingView Notification Schedules Silence Webhooks Too: A New Cause of Silent Auto-Trade Failures

Your alert is still marked Active in green, Alert Manager still shows the trigger firing, but the webhook hasn't received a single signal all day — and the culprit this time may be TradingView's notification schedule, which shipped in July 2026. Nobody told you the schedule pinned to that alert probably isn't one you set for it. It got there by itself.

This piece doesn't retread the network-level webhook checks. IP allowlists, ports, the 3-second timeout, exchange rejections — the site already has a complete five-layer flowchart covering that ground, and this article doesn't repeat it. It does one thing: it explains the notification-schedule cause that only appeared in July 2026, and it marks out which sentence is TradingView's own wording and which is our derivation.

TradingView Wrote One Line About Notification Schedules and Webhooks — And That Line Is Decisive

The feature is called notification schedule. It lets you specify, per alert, the days and times when push, email, or webhook notifications are allowed to go out. That reads like a pure UX improvement — until you get to the paragraph in the announcement aimed at automated traders.

Those two lines are TradingView's own words, not a paraphrase, and the announcement itself names webhooks specifically. Weight them accordingly — they are the only official authorization this piece needs, and everything else is derived from them.

Suppressed Triggers Don't Vanish — They Get Written Quietly to the Alert Log

The announcement describes the mechanism this way: when an alert fires outside its scheduled window, TradingView silences that notification but continues to monitor the condition, and the event is still silently recorded in your alert log. In other words, the trigger history is complete — only the delivery step is missing.

This is exactly the kind of failure that takes the longest to find. It doesn't complain, it doesn't bounce, and it doesn't blow up while you're watching. You open Alert Manager, see every trigger neatly listed, and naturally start hunting downstream — your server logs, your exchange rejections. You lose a day there.

The Real Landmine Is Sticky Settings: You Didn't Set It, It Sets Itself

If notification schedules only took effect when you set them explicitly, this article wouldn't need to exist. The problem sits in the second half of the same announcement — TradingView shipped a convenience feature called sticky settings at the same time.

What the announcement says

The original wording is that sticky settings will"automatically remembers your last-used schedule and applies it by default when you create your next alert, where applicable."The announcement also gives you three ready-made presets: Weekdays, Standard working hours (09:00–18:00), and a Custom schedule.

Where this inference reserves judgment

The official sentence about sticky settings ends with the qualifierwhere applicable, and TradingView doesn't define which cases count as applicable. Which means we can't even promise “it always propagates” on TradingView's behalf — the inheritance might be limited to same-type alerts, or there may be other exclusions.

“Once Only” Alerts Have an Exception, But It Doesn't Save Automation

The announcement does carve out a path for one-shot alerts: if aOnce Only alert fires during a muted window, TradingView doesn't silently disable it. The event is logged, the alert stays active, and the notification is sent the next time the condition is satisfied inside the scheduled window. That is the official mechanism, not our reading.

For manual chart watchers this is a nice touch — your one-shot alert doesn't get burned for nothing. For an auto-trader the same sentence reads inverted — it pushes a signal to a different point in time.

Six Notification Channels, and the Official Text Only Says “All Outbound”

When the announcement introduces the feature, it names three channels: push, email, webhook. But the warning aimed at automated traders uses the phrase all outbound channels, which is a wider set — and the TradingView Help Center actually documents six notification channels.

This table is a reference — you don't need to memorize it.For an automation-facing reader the only row that matters is the first one: webhook is explicitly named. The other four channels aren't individually addressed, so don't fill in the blanks on TradingView's behalf — especially Sound and Toast, which play inside your own browser. Whether they count as “outbound” isn't something TradingView wrote down.

How to Check Whether Your Automation Alerts Are Muted by a Schedule

The announcement points to a signal you can inspect directly: alerts with a schedule enabled show a calendar icon next to their status in Alert Manager, and hovering the icon reveals the active dates, times and timezone in a tooltip. Conversely — alerts without a schedule don't have that icon.

• Open Alert Manager and scan every alert that owns an auto-trading workflow — check whether a calendar icon sits next to the status.
• For each one that shows an icon, hover it and confirm the days and times shown are 24/7. Anything saying “Weekdays” or “09:00–18:00” is the trap firing.
• Set the schedule on every automation alert back to 24/7. That's the exact recommendation the announcement gives.
• Once you've fixed those, go back and audit every alert you've created recently — sticky settings don't strike once, they keep propagating.

These steps are laid out from the interface as described in the official announcement. We haven't hands-on tested this feature ourselves, so the exact layout and icon positions may already have changed. One more thing to be clear about: as of 2026-07-30, the Help Center's “Introduction to TradingView alerts” makes no mention of notification schedules at all — this feature is only documented in the July 2026 blog post.

Which means the timezone the schedule uses — chart timezone, account setting, exchange timezone — has no documentation to point at. The announcement only says the tooltip displays a timezone; it doesn't say which one that is. If you trade across timezones, take what's shown in the tooltip as the source of truth.

Where This Layer Fits Into the Webhook Debugging Flowchart

The site's webhook five-layer diagnostic flowchart was written before this feature shipped, so it doesn't include this cause. Worse, a schedule-muted alert lands squarely inside the flowchart's Layer 2 “no error message” branch, which then routes you toward “the problem is more likely on your server or network side.” Exactly the wrong direction.

There's one distinction worth calling out on its own:a muted trigger and a failed send look nothing alike.A failed send leaves an error in the alert log; a muted trigger leaves no error at all, because it never attempted to send. A slow-arriving signal is yet a third case — the site's webhook latency breakdown handles that one.

An Honest Paragraph: This Is a New Feature and We Don't Have Live-Trading Data

We haven't tested this feature ourselves, and this piece doesn't pretend we have. Every official statement above has a citation and a verification date; every derivation is labeled as a derivation. What we don't have is a live-trading log that could tell you “schedule muting caused X missed trades in the wild” — we can't produce that number, so we don't write it.

This is also a feature that only went live on 2026-07-07. What we've summarized here is TradingView's stance at that moment in time, not a permanent spec — TradingView made no commitment that the behavior won't change, so before you act on anything here, go re-check the announcement and the Help Center yourself.

One last note about tooling, and a self-imposed limit while we're at it. Any execution end — including ours — can only tell you “I didn't receive it.” TVSBot, for example, keeps a per-signal log of everything it actually received and lets you replay each one, but it can't tell the difference between a schedule-muted signal, a signal TradingView never sent, and a signal lost to the network.

That distinction can only be settled by TradingView's own alert log. This kind of upstream refusal to confirm delivery is a structural limit designed into TradingView itself — swapping the execution end out won't remove it.

Frequently Asked Questions