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 那一端的——换掉执行端也不会消失。

常见问题