微信自动回复全挂：一个看门狗cron把自己举报进了死循环

8月16号晚上开始，我给 Hermes 发微信，消息能发进去，回复一个都收不到。翻 gateway.log，从 21:27 起每 16 分钟冒一条 iLink sendmessage rate limited; cooldown active for 30.0s，一直刷到第二天我找上门。

固定16分钟一次，不像偶发限流

第一反应是微信接口又在限流。但"每16分钟一次"这个节奏太规律了，限流不会踩得这么准。往回追，找到两个 LLM cron 挂在 jobs.json 上报 error：丑木木博客 8/15 超时、SEO 巡检 8/10 超时，都是 TimeoutError: idle for 600s。

那个看门狗（cron_error_watchdog，每15分钟跑一次）检测到 error，就开始推微信报警。问题就出在这一步。

它把自己举报了

链路是这样的：

• 看门狗推微信报警 → 被 iLink 限流拒发
• 这次"拒发"被写回它自己的 last_delivery_error
• 下一轮它一查"有新的交付失败" → 又推一次 → 又被拒

循环锁死。它每15分钟自产一个"交付失败"，再自己去报这个失败，报的过程又制造新的失败。微信那边的发送熔断被它一次次重新打开，所有 outbound 全被拒——包括我正常对话的自动回复。而我发的消息（inbound）根本不受影响，所以现象特别诡异：话能说进去，回复一个收不到。

实锤的一刻：看门狗自己的 last_delivery_error 里，躺着的就是那条限流错误串。它在反复上报自己。

先止血，再修根

三步走完：

# 1. 立即停掉看门狗，切断推送源
cronjob pause cac2f3821fd8

# 2. 修脚本，让它跳过自己
for job_id in all_jobs:
    if job_id == "cac2f3821fd8":   # 别举报自己
        continue

# 3. 恢复监控
cronjob resume cac2f3821fd8

还有个关键发现：发送熔断是 gateway 进程的内存态，30秒自动过期。所以只要停掉推送源，根本不用重启 gateway，发送立刻就恢复了。

修完清点损失

微信自动回复恢复。顺带清点漏发：博客最新文章停在 8/9，是 8/15 那次超时漏发的，下次 cron 会自动补上；看板那种没选中内容的空跑，不算漏发。

教训：任何监控/告警类的定时任务，"排除自己"是硬性要求，不是可选项。以后再遇到"消息能进、回复发不出"，先 grep 日志看 send failed 的节奏，再查是哪个推送源在反复刷——别一上来就怀疑代码或网络。