以下以 OpenClaw v2026.9.8 的版本文件為基準。這版使用 openclaw automations 管理工作，openclaw cron 仍是別名；命令是供操作者檢查與設定的範例，本篇沒有連線到 Gateway 執行或傳送通知。先在自己的環境執行 openclaw --version 與 openclaw automations --help，確認安裝版本符合語法。

先找原工作，保留三層證據#

在可以連到目標 Gateway 的終端機執行以下唯讀命令。JOB_ID 要換成 list --all 中的原工作 ID，不能直接貼上尖括號占位符：

1
openclaw gateway status
2
openclaw automations status
3
openclaw automations list --all
4

5
JOB_ID='替換成原工作ID'
6
openclaw automations get "$JOB_ID"
7
openclaw automations show "$JOB_ID"
8
openclaw automations runs "$JOB_ID" --limit 20

get 用來讀儲存定義，show 包含解析後的投遞路由，runs 則追蹤發生過的執行。依版本文件的管理說明，執行 status 與整次工作的 completionStatus 是不同欄位：status: ok 不能單獨證明通知已成功。

檢查層	保留的資訊	下一步
排程	enabled、schedule、時區、下一次時間	確認原工作真的啟用，換算成台北時間
執行	該次 run ID、status、錯誤或 skipped 原因	找到同一次工作，而非只看最近成功的一筆
投遞	completionStatus、delivery error 或 suppression reason	確認是失敗、刻意不送，或結果未知

紀錄可以只留本機，分享排錯資料前遮蔽收件人、工作提示詞與帳號資訊。這三層證據的用途是縮小修復範圍，不是要求你把整份 transcript 貼出去。

台北早上七點，要寫時區而不是只寫七點#

0 7 * * * 只描述時鐘上的七點。依 v2026.9.8 排程規則，沒有 --tz 的 cron 使用 Gateway 主機時區；沒有 offset、也沒有時區選項的 at 時間則按 UTC 解讀。

確認原工作的目標確實是「台北每天七點」後，可以修改原工作，避免另開一份相同排程：

1
JOB_ID='替換成原工作ID'
2
openclaw automations edit "$JOB_ID" \
3
  --cron '0 7 * * *' \
4
  --tz 'Asia/Taipei'
5
openclaw automations get "$JOB_ID"
6
openclaw automations show "$JOB_ID"

這是會修改排程的命令。保存後核對下一次時間；單純把提示詞寫成「台灣時間」不能替代 schedule 的時區設定。也不要直接把主機時區改掉來修單一工作，其他沒有明確時區的工作可能一起變動。

一次性提醒則可明確寫 offset：2026-10-08T07:00:00+08:00 對應 2026-10-07T23:00:00Z。注意 UTC 日期是前一天，不要只比較日期字串就判斷工作提早執行。需求若是每天固定鐘點，選 cron；--every 1d 表達固定間隔，不能當成每天七點的替代設定。

官方另對分鐘為 0、小時為萬用字元的整點循環提供預設 stagger；0 * * * * 屬於這種情況，固定七點的 0 7 * * * 則不符合該條件。不要把所有「晚幾分鐘」都歸因於 stagger，還要看工作是否排隊、執行或投遞花了時間。

有 run 卻沒有通知，從投遞設定查起#

同一次 run 的 status: ok 加上 completionStatus: failed，可能是執行成功、必要投遞失敗。unknown 也不能當作已送達；先核對收件端，避免立即重送造成重複訊息。

版本排錯文件列出了幾個具體方向：

delivery.mode: none 沒有 runner 的 fallback 投遞；有權限與路由的 agent 仍可能自行使用訊息工具，所以它也不是禁止所有對外訊息的開關。
channel、to 缺少或無效，先修原工作的目的地；unauthorized、Forbidden 則回到該通道帳號與權限查證。
deliverySuppressionReason 表示刻意抑制投遞，和 delivery error 不同。isolated 工作只回覆 NO_REPLY 時，不應期待一份一般通知。

若目標是 Telegram 群組話題，還要核對群組與 topic ID；這部分可接著看 OpenClaw Telegram Group Topics 設定。有多個通道或帳號時，不要依賴「上次聊天」推測每日通知會去哪裡。

沒有任何 run，則先回到排程層：Gateway 是否持續運行、工作是否啟用，以及 cron.enabled 和啟動環境中的 OPENCLAW_SKIP_CRON 是否停用了自動執行。找得到 run 但被 skipped，應依該筆原因處理 agent、帳號或服務狀態，不能只增加重試次數。

修好設定後，用同一次 run 驗收#

手動觸發可能呼叫模型、執行工具並發送通知。先確認提示詞不會重複寫入資料或產生重複通知，再於可接受的測試目標執行：

1
JOB_ID='替換成原工作ID'
2
openclaw automations run "$JOB_ID" --wait --wait-timeout 10m
3
openclaw automations runs "$JOB_ID" --limit 5

官方文件說明，不加 --wait 的 run-now 命令在排入佇列後就會返回；這不能證明工作結束。驗收時記下回傳的 run ID，確認該筆的執行結果、整體完成狀態及收件端內容，再等下一次自然排程核對時間。手動成功驗證工作路徑，下一次自動成功才驗證排程路徑。

本篇的命令、欄位與時區規則已依版本文件檢閱，沒有在 OpenClaw runtime 做端到端測試；通道憑證、模型可用性與實際收件結果仍需在你的 Gateway 驗證。若還要升級安裝版本，請把 OpenClaw 升級與訊息驗收和排程修復分開，避免同時改太多變因。

參考資料：

OpenClaw v2026.9.8：Automation schedules

OpenClaw v2026.9.8：Manage automations

OpenClaw v2026.9.8：Automation troubleshooting

OpenClaw v2026.9.8：Automation delivery