Cloudways WordPress Cron 排錯教學：由排程延遲到背景工作驗證

WordPress 的 WP-Cron 不是獨立常駐服務，而是由訪客請求觸發。當網站流量低、快取規則不當、PHP worker 排隊或外部 API 逾時，排程可能延遲，令備份、電郵、訂單和清理工作未按時執行。本文提供六步 Cloudways 排錯流程，先從 Monitoring 找證據，再逐項測試排程。所有截圖中的 IP、網域、電郵、帳戶、伺服器和應用程式名稱均已遮蔽。

排錯前先記錄排程

記下事件名稱、預定時間、最近一次成功時間和實際完成時間。不要把客戶電郵、訂單編號或 webhook token 放入公開記事；用匿名事件名稱和時間差保存基線。

步驟 1：查看資源總覽

在 Cloudways Monitoring 選擇排程延遲的時間範圍，先比較 CPU、RAM、Swap、I/O 和流量。若同一時間資源接近上限，先處理容量或慢查詢，再判斷是不是 Cron 本身故障。

步驟 2：建立排錯前備份

修改排程或停用外掛前先建立按需備份，記錄備份完成時間。不要在備份進行中同時清除佇列或重啟服務，否則出現問題時無法還原清晰的基線。

步驟 3：檢查 PHP 與 worker 容量

核對 PHP worker 是否長時間滿載、RAM 是否使用 Swap，以及是否有大量未快取的後台請求。可以先在 Staging 測試降低排程併發或分散執行時間，不要在正式站同時改多項設定。

步驟 4：覆核排程及維護設定

檢查 WordPress 的排程清單、伺服器時區、網站時區、禁用 WP-Cron 設定及任何系統 Cron。若改用伺服器 Cron，確認命令和執行使用者權限正確，並以遮蔽後的示範路徑保存設定。

步驟 5：等待並查看工作狀態

手動執行一個低風險測試事件，觀察工作是否進入佇列、執行及完成。不要反覆點擊，否則可能產生重複電郵或重複訂單；若失敗，記下已遮蔽的錯誤類型和時間。

步驟 6：驗證排程結果及日誌

檢查文章發布、清理暫存、備份、電郵及第三方 webhook 是否在預期時間完成，再對照 PHP 錯誤日誌和 Monitoring。觀察一個高峰週期後，才移除舊排程或調整頻率。

常見問題：應否永久停用 WP-Cron？

不一定。高流量網站可能適合由系統 Cron 觸發，但要先確認命令、權限、時區和錯誤記錄；低流量網站直接停用可能令重要工作永不執行。

常見問題：排程重複執行怎麼辦？

先檢查是否同時保留 WP-Cron、系統 Cron 和外掛自訂排程，再暫停其中一個測試。任何修改前先備份，並觀察是否仍有重複事件。

總結

WP-Cron 排錯應從資源、備份、worker、時區、觸發方式和結果六方面驗證。以時間軸保存證據，比單純手動按一次「Run」更容易找出真正原因。