TradingView 通知排程會靜音 webhook：自動下單沒反應的新成因

Alert 還是綠色的 Active、Alert Manager 裡也看得到觸發紀錄， 你的 webhook 卻整天沒收到任何一筆訊號——這一次的成因可能是 TradingView 在 2026 年 7 月新增的通知排程。 沒有人先跟你講的是：那個排程很可能不是你替這個 alert 設的， 是它自己套上來的。

這篇不重講 webhook 的網路層排查。IP 白名單、port、3 秒逾時、 交易所拒單那幾層，站上已經有 完整的五層流程圖 在處理，這篇不重複。這篇只做一件事：把通知排程這個 2026 年 7 月才出現的成因講清楚，並且明確標出哪一句是官方寫的、 哪一句是我們推導的。

TradingView 對通知排程與 webhook 只寫了一句話，但那句話是決定性的

這個功能叫 notification schedule，官方繁中版譯成「通知排程」。 它讓你替單一個 alert 指定允許發送推播、email 或 webhook 的日期與時間。聽起來是純粹的體驗改善——直到你讀到公告裡 給自動化交易者的那一段。

這兩句是官方自己寫的，不是誰推導出來的， 而且官方在公告裡主動點名了 webhook。 所以這一句的份量要看重——它是這篇文章唯一需要的官方授權， 剩下的都是從它推出去的。

被靜音的觸發不會消失，它會安靜地寫進 alert log

公告對機制的描述是：alert 在排程時間之外觸發時， TradingView 會靜音那則通知，但仍然持續監控 alert 條件， 而該事件仍會靜默記錄在你的 alert log 裡。 也就是說，觸發紀錄是完整的——缺的只有送出這一段。

這正是最難查的那種壞法。它不會吵、不會退回、不會在你檢查的時候爆—— 你打開 Alert Manager，觸發紀錄一筆一筆都在， 於是你自然會往下游找原因，去看伺服器 log、去看交易所拒單， 然後在那邊耗掉一整天。

真正的地雷是 sticky settings：你沒設，它自己套上來

如果通知排程只在你主動設定時生效，這篇文章就不必寫。 問題出在同一則公告的下半段——官方同時上了一個叫 sticky settings（官方繁中版譯成「固定設定」）的便利功能。

官方寫了什麼

公告的原文是：sticky settings 會「automatically remembers your last-used schedule and applies it by default when you create your next alert, where applicable」， 官方繁中版譯成「系統會自動記住您上次使用的排程， 並在建立下一個快訊時（適用情況下）預設套用該設定」。 官方同時提供三個現成選項：工作日、標準工作時間（上午 9:00 至下午 6:00）、 以及自訂排程。

這條推論的保留在哪裡

官方在 sticky settings 那句話裡留了 where applicable這個保留字，而官方沒有定義哪些情況算 applicable。 所以連「一定會套用」這件事都不能替官方保證—— 它可能只在同類型 alert 之間繼承，也可能有其他排除條件。

「僅一次」alert 有例外，但那個例外救不了自動化

公告有替一次性 alert 留一條後路：如果 Once Only 的 alert 在靜音期間觸發，系統不會在沒有通知你的情況下把它停用； 事件會被記錄，alert 保持啟用，並在下次於排程時間內符合條件時才發送通知。 這是官方原文寫的機制，不是我們的解讀。

對手動盯盤的人來說這是好設計——你的一次性 alert 不會被白白消耗掉。 但對自動下單來說，這句話要反過來讀——它把一筆訊號推到了另一個時間點。

六個通知管道，官方只說「所有外部管道」

公告介紹功能時點名了三個管道：推播、email、webhook。 但給自動化交易者的警語用的字是 all outbound channels， 範圍比那三個大——而 TradingView 說明文件裡列出的通知管道其實有六個。

這張表是給你比對用的，不用背。對自動化讀者真正重要的只有第一列：webhook 被官方明文點名了。 其餘四個管道官方沒有逐一交代，那就不要替官方補完—— 尤其 Sound 與 Toast 是在你自己的瀏覽器裡播的， 它們算不算 outbound，官方沒有寫。

怎麼確認你的自動化 alert 有沒有被通知排程靜音

公告寫了一個可以直接觀察的訊號：有啟用排程的 alert， 會在 Alert Manager 的狀態旁顯示一個日曆圖示， 把滑鼠移上去就會在提示框裡看到啟用的日期、時間與時區。 反過來說也成立——沒有排程的 alert 不會有這個圖示。

• 打開 Alert Manager，逐一看你所有負責自動下單的 alert，狀態旁邊有沒有日曆圖示。
• 有圖示的就 hover 上去，確認顯示的日期與時間是不是全天候。 看到「工作日」或「上午 9:00 至下午 6:00」就是中獎了。
• 把自動化 alert 的排程改成全天候，這是官方在公告裡直接給的建議。
• 改完之後，回頭確認你最近新建的每一個 alert—— sticky settings 的影響不只一個，它會一路沿用下去。

這幾步是依官方公告描述的介面整理的，我們沒有替這個功能做過實機操作， 實際版面與圖示位置可能已經改過。另外要講清楚一件事： 截至 2026 年 7 月 30 日查證，Help Center 的 〈Introduction to TradingView alerts〉整篇沒有提到通知排程， 這個功能目前只有那則部落格公告寫過。

所以排程是用哪個時區當基準——圖表時區、帳號設定、還是交易所時區——官方沒有可引用的說明。公告只說 tooltip 會顯示時區， 沒有說那個時區跟著誰。跨時區交易的人請以自己在 tooltip 裡看到的為準。

這一層該補進哪張 webhook 排查流程圖

站上那張 webhook 五層診斷流程圖 寫在這個功能上線之前，所以它沒有收錄這個成因。 更麻煩的是，被排程靜音的 alert 會走進那張圖第 2 層的 「沒有錯誤訊息」分支，然後被導向「問題比較可能在你的伺服器或網路端」——方向剛好是錯的。

這裡有一個分辨的關鍵，值得單獨講：被靜音跟送出失敗長得完全不一樣。送出失敗會在 alert log 留下錯誤，被靜音不會留下任何錯誤， 因為它從來沒有嘗試送出。至於訊號有到但很慢，那又是第三種情況—— 站上另一篇 webhook 延遲拆解 處理的是那個。

誠實的一段：這是新功能，我們沒有實單資料

我們沒有替這個功能做過任何實測，這篇也不會假裝有。上面每一句官方陳述都附了來源與查證日期，每一句推論都標了是推論。 我們沒有實單紀錄可以告訴你「排程靜音在真實交易裡造成了多少漏單」—— 那種數字我們拿不出來，所以不寫。

另外，這是 2026 年 7 月 7 日才上線的功能。 這篇整理的是那個時間點的官方說法，不是永久不變的規格—— TradingView 沒有承諾行為不會改，實際動手前建議自己再去公告與 Help Center 查一次。

最後補一件跟工具有關的事，也順便自曝限制。 任何執行端——包括我們自己的——能告訴你的只有「我沒有收到」。 舉例來說，TVSBot 會把每一筆實際收到的訊號留下紀錄可以逐筆回放， 但它分不出來你的訊號是被排程靜音、是 TradingView 沒送、還是網路掉了。

那個差別只能回 TradingView 的 alert log 看。這種 上游不給你送達確認 的結構性限制是設計在 TradingView 那一端的——換掉執行端也不會消失。

常見問題