WooCommerce 排程工作積壓：重跑之前先看哪幾個訊號
後台一打開，Pending 幾百、Failed 幾十、還有幾個 In-progress，最直覺的反應是「全部重跑」。但在 WooCommerce，排程工作不是純粹的內部家務：一個 action 可能正在收款、建立續訂單、扣庫存、發交易電郵、通知 CRM，或向外部 webhook 送出資料。重跑的正確與否，取決於它做過甚麼，而不是只取決於它現在顯示甚麼狀態。
本文處理排程工作積壓的分流與重跑前證據。它不重複換主機後營運驗收、更新後功能回歸、PHP runtime 相容性、安全訊號、還原演練或隔離 staging的完整清單；本篇只聚焦一件事：見到積壓時，怎樣先判斷，再決定是否重跑。
本文不提供「一鍵重跑」、「全部取消」或「批量刪除」的安全承諾。 也不建議未查明 runner 與現有 cron 前，盲目新增另一個 cron。Action Scheduler 的狀態、日誌與系統狀態是分流證據，不是外部付款、電郵或 webhook 是否已完成的證明；最終仍要對照業務資料與外部服務。
一、先看業務影響，不要由「數字很大」開始
積壓數量本身不是優先次序。先按工作類型問三個問題：它會不會動錢、會不會對外說話、會不會改動不可逆的業務資料？
| 工作類型 | 可能的業務影響 | 重跑前先看 |
|---|---|---|
| 付款、續訂、退款 | 重複收款、漏收款、訂單與訂閱狀態不一致 | 付款商交易紀錄、訂單備註、續訂單狀態、訂閱狀態 |
| 交易電郵、客服通知 | 重複發信、漏發、客戶收到錯誤狀態 | 郵件服務紀錄、收件人、寄送時間、範本與觸發來源 |
| 庫存、優惠券、會員權限 | 重複扣減、錯誤解鎖、權限殘留 | 訂單與商品庫存、優惠券使用紀錄、帳戶與角色變更 |
| webhook、CRM、ERP 同步 | 外部系統重複建立紀錄或覆蓋較新資料 | 對方 endpoint 的收件紀錄、resource ID、更新時間 |
| 報表、清理、一般維護 | 延遲報表、暫存資料增加，通常可較後處理 | 是否影響付款或客戶通知；可否安全分批 |
同一條 backlog 內可能同時有上述各類工作。先隔離會動錢與會對外發送的工作，再處理純內部、可重算的工作；不要因為某個 hook 數量最多，就把它當成最緊急。
二、四個狀態不是同一種積壓
Action Scheduler 的管理畫面可按狀態篩選，亦可查看單一 action 的日誌、hook、group、預定時間與 claim ID [2]。分流時至少分開以下四類：
1. Failed：有一次嘗試已經失敗
Failed 可能代表 callback 留下錯誤，也可能只是超過 Action Scheduler 預設的五分鐘 timeout 假設而被標記失敗；官方明言，若所有 callbacks 在 timeout 後才成功完成，狀態其後可再更新為 completed [10]。所以它不是「已經終止」的證明。付款可能已被 capture，但訂單沒有更新；電郵可能已由上游寄出，只是 action 其後出錯；webhook 對方可能已收貨，只是回應超時。要看該 action 的日誌，也要看外部服務與業務物件的實際結果。
2. Pending：未開始，但「未來」與「已過期」要分開
未到預定時間的 Pending 是正常排隊，不是積壓，不應為了「清數字」而提前推進。已過預定時間仍未開始的 Pending，才是 overdue。 Action Scheduler 官方說明，past-due 是因 WP-Cron 的運作方式而可能出現；若有多個 past-due 工作已超過一天，就可能代表站點有問題 [1]。一天是官方診斷例子，不是安全等待門檻。 若 overdue 涉及付款、庫存或客戶通知，即使只是幾分鐘，也應即時調查影響。
3. In-progress：已開始，不應自動當成卡死
In-progress 可能正在跑長時間任務，也可能是 runner 已接手但尚未完成。除非已有明確的 claim、timeout 或錯誤證據，不要自動取消再重跑；這樣可能製造兩個同時執行的 callback。WooCommerce Subscriptions 的文件指出，與訂閱相關的 action 若執行超過五分鐘，會按 timeout 處理並標記失敗 [8]；但這是該領域文件的門檻，不應直接當成所有 action 的通用 SLA。
4. Complete／Canceled：是歷史，不是待處理
這兩個狀態通常不屬 backlog。把它們與 Pending 混在一起，會令團隊誤以為佇列更長。若需要清理，仍要先確認保留期與稽核需要；尤其 Failed 在 Action Scheduler 4.0.0 起預設保留三個月後清理，版本與 filter 可改變此行為 [7]。不要假設失敗證據會永遠存在，也不要未保存證據就批量清除。
三、WP-Cron 與 Action Scheduler：一個是觸發，一個是工作佇列
WP-Cron 是 WordPress 的時間排程系統。官方文件說明，WP-Cron 在頁面載入時檢查到期工作；它不會像系統 cron 一樣持續運行，若 14:00 有工作但 17:00 才有頁面載入，工作便可能延後 [6]。
Action Scheduler 則是較大型的工作佇列。它預設由 WP-Cron 及管理員請求的 shutdown hook 啟動，但官方明言它不硬性依賴 WP-Cron，也可由其他 runner 啟動 [1]。Action Scheduler 的 WP-CLI runner 適合長時間或大量工作；官方亦提醒，如停用預設 runner，就必須確保仍有其他 runner 真正執行工作 [4]。
因此，「WP-Cron 有事件」不等於「Action Scheduler 有進度」；「Action Scheduler 有 pending」也不等於「要再加一個 cron」。先確認現有 runner 是甚麼、有沒有被觸發、有沒有完成 claim、上次成功是幾時，再決定是否處理 runner，而不是盲目疊加第二個排程器。
若站點已由主機系統 cron、WP-CLI 或自訂 runner 推動 Action Scheduler，再加入一個未協調的 WP-Cron 或系統 cron，可能造成重複觸發與資源競爭。應先記錄現有觸發方式、時間、重疊與錯誤，再交由有權限的人處理。
四、儲存位置要看現代文件：舊 Woo 頁面仍有 CPT 說法
這是一個容易誤判的地方。WooCommerce 的 Scheduled actions 文件仍描述 Action Scheduler 以 scheduled-action custom post type 儲存工作 [5]；但 Action Scheduler 官方 FAQ 明確指出，3.0 或以上已改用 actionscheduler_ 前綴的 custom tables，3+ 會由舊 CPT 遷移 [1]。
本文以 Action Scheduler 自身的現代 storage 說明為準。實務上仍要確認站點的 data store，因為 Action Scheduler 的 storage 是可替換的；不要只憑一篇文章就假設所有站點都使用同一組資料表。重點不是背誦表名，而是：不要用錯年代的資料模型去判斷 backlog，也不要在未確認 store 前執行清理或改表。
五、重跑前要留的五組證據
不要只截一張「Failed 很多」的圖。每一組準備重跑的工作，至少留下以下紀錄：
- Action 身分與時間：action ID、hook、group、args、預定時間、claim ID、最後更新時間與時區。
- 狀態與日誌：Pending／In-progress／Failed 的實際時間點；Failed 的錯誤訊息與前後 log，不要只留最後一行。
- 業務物件：相關 order ID、subscription ID、customer ID、product／variation ID，以及訂單備註與狀態。
- 外部結果：付款商交易、退款、郵件服務寄送紀錄、webhook 對方收件紀錄、CRM／ERP resource ID。
- Runner 證據：現有 WP-Cron 事件、系統 cron、WP-CLI 或自訂 runner 的執行紀錄，以及失敗前後是否有部署、憑證、網絡或供應商變更。
證據要能回答：「這個 action 嘗試了幾次、做到了哪一步、外部世界現在是甚麼狀態」。只知道 status = failed，仍不足以決定重跑。
上述紀錄可能包含 args、customer／subscription ID、聯絡資料、付款詳情、token 或 webhook payload。應只讓有需要的人存取；分享給供應商、客服或外部群組前，先遮蔽客戶與聯絡資料、付款詳情、access token、cookie／session 及不必要的個資。日誌可以證明問題，但不需要把完整敏感資料四處傳。
六、用一張表決定：hold、reconcile 還是可選擇性重跑
| 情況 | 判斷 | 下一步 |
|---|---|---|
| 未到期的 Pending | 正常排隊 | 不當成積壓；觀察 runner 是否按時推進 |
| 多個 overdue 超過一天，runner 無進度 | runner／環境異常 | 先查觸發、錯誤與資源；不要先批量重跑 |
| Failed，外部結果確認未發生，原因已修正，且沒有 active callback／自動付款重試 | 可考慮選擇性重跑 | 只限最小範圍，保留 due time／order／依賴，並即時核對結果 |
| Failed，外部結果已發生或 unknown | 先對帳，不重跑 | 核對付款、訂單、電郵或 webhook；必要時由負責人修正業務狀態 |
| In-progress，仍在執行 | 等待與觀察 | 不自動取消、不重複建立同一工作 |
| In-progress 已有明確 timeout／claim 異常 | 需人工判斷 | 先保存證據與確認沒有仍在跑的 callback，再交由有權限的人處理 |
| 舊 Failed 將近清理期 | 證據可能消失 | 先保存必要紀錄，再決定保留或清理政策 |
這張表的核心不是「failed 就可以重跑」，而是：只有當原因已修正、外部效果已確認、callback 可安全重複，才可考慮最小範圍重跑。
七、冪等性與付款對帳：重跑前最容易被跳過的一步
「重跑」不是回復原狀，而是再執行一次 callback。若 callback 不是冪等，重跑可能重複發信、重複建立 CRM 紀錄、重複扣庫存，甚至再次向付款商發出請求。Action Scheduler 4.0.0 在啟用 unique 排程選項時，會把 arguments 納入判斷，避免建立相同的 pending／running action [7]；但這種排程層的去重，不等於 callback 本身冪等，也不等於外部服務沒有收過第一次請求。
付款與訂閱尤其要另外對帳。WooCommerce Subscriptions 的官方錯誤指南要求先分清「付款未 capture」與「付款已 capture 但訂單／訂閱未更新」，再分別處理 [8]。其重試文件亦把續訂付款重試與訂單、訂閱狀態連在一起 [9]。這代表：Action Scheduler 的一個 failed 訊號，不能取代付款商交易與訂單備註的對帳。
對這類工作，重跑前至少確認：
- 付款商是否已有成功交易、授權或退款；
- 本地訂單與續訂單是否只是狀態未更新；
- 訂閱是否仍應保持啟用、暫停或取消；
- 重跑會否建立第二張續訂單或第二次扣款；
- 客戶通知是否已發出，重跑會否重複打擾。
若上述任何一項是 unknown，應先 hold and reconcile，而不是把工作推回 pending。
八、修正原因，再選擇最小重跑範圍
重跑只是把同一個問題再執行一次。若原因是 runner 停止、付款商憑證失效、API rate limit、記憶體不足、fatal error、資料格式錯誤或網絡中斷，應先修正原因，否則只會得到另一批 failed。
修正後的重跑應符合四個條件：
- 範圍最小但不破壞次序：即使按單一 hook、group 或小批次處理，也要保留原本 due time、先後次序與跨 group 依賴；不要把未到期的 future pending 提前。
- 沒有仍在跑的重複執行：先確認沒有 active callback、未清理的 claim，或已排定的自動付款重試，才考慮手動選擇性重跑。
- 外部效果已知：已確認沒有重複收款、重複發信或重複 webhook；若有，先完成對帳。
- 可即時驗證：重跑後短時間內可檢查 status、log、訂單、付款商、郵件與 webhook，而不是等到下一次日結才發現重複。
Action Scheduler 的預設 runner 會以批次處理工作，並受每次請求的時間與批次大小限制；官方文件提醒，提高處理門檻可能令站點承受不了，必須先測試 [3]。所以「把全部工作一次跑完」不是可靠的復原策略，反而可能把一個積壓變成資源耗盡或外部重複操作。
九、重跑後要驗甚麼
重跑完成不等於修復完成。最少要驗：
- 同一 action 是否由 failed／pending 轉為 complete，且沒有新的重複 action；
- 日誌是否仍有相同錯誤，或有新的 timeout／rate limit；
- 訂單、續訂單、訂閱與庫存是否與付款商及業務預期一致；
- 客戶與客服通知是否只送一次，內容是否正確；
- webhook／CRM／ERP 是否只有一個業務結果，而不是多個重複 resource；
- runner 是否在下一個週期仍能正常推進，而不是只成功一次。
若任何外部結果不一致，應停止再重跑，先保存證據並交由付款、客服或平台負責人對帳。「status 變成 complete」只證明 callback 沒有在該次執行中報錯，不證明業務結果正確。
六步分流：先證據，後重跑
- 01 · 業務影響付款、通知、庫存與 webhook 先分開
會動錢或對外發送的工作優先；數量多不等於最緊急。
- 02 · 狀態與時間overdue、future pending、failed、in-progress
未到期不是積壓；in-progress 不可自動當成卡死。一天不是等待門檻，付款或通知即使幾分鐘 overdue 也要查。
- 03 · Runner 證據WP-Cron 觸發不等於工作完成
先確認現有 runner、claim 與 storage，不要盲目加第二個 cron。
- 04 · 外部對帳日誌、訂單、付款商、電郵與 webhook
沒有紀錄不等於沒有發生；證據受限存取，分享前遮蔽客戶、聯絡、token 與付款資料。
- 05 · 原因與範圍原因未修正／外部效果未知＝hold
保留 due time、次序與依賴；確認沒有 active callback／自動付款重試，才考慮最小重跑。
- 06 · 重跑與驗證status、日誌、業務資料一起看
complete 不代表業務正確；出現重複即停止再重跑並對帳。
記住：未到期 Pending 不是 backlog；Failed 不代表沒有外部效果；In-progress 不應自動取消；批量 cancel／delete／retry 不是安全預設。
下載完整 SVG 流程圖十、常見問題
Pending 數量很多，是否一定要全部重跑？
不是。先分開未到期的正常排隊與已過期的 overdue。未到期工作不應提前推進；多個 overdue 超過一天是官方列出的診斷例子，並非等待門檻；涉及付款、庫存或通知時應即時檢查 runner 與環境 [1]。
Failed 是否代表工作完全沒有做過？
不是。Failed 可能是 callback 錯誤，也可能只是預設的五分鐘 timeout 假設；callbacks 之後成功完成時，狀態可再變成 completed [10]。付款、電郵或 webhook 也可能已部分完成。WooCommerce Subscriptions 的官方錯誤指南要求分開核對付款是否已 capture 與訂單／訂閱是否更新 [8]。
In-progress 很久沒有變化，可以直接取消再重跑嗎？
不應自動這樣做。先確認 claim、執行時間、timeout 與日誌，並確定沒有另一個 callback 仍在跑；不同工作類型與外掛的 timeout 規則可能不同。未確認前，取消再重跑可能製造重複外部操作。
WP-Cron 沒有事件，是否立即新增一個 cron？
不應先加。Action Scheduler 預設可由 WP-Cron 與管理員請求啟動，也可由其他 runner 推動 [1]。先確認現有觸發方式與是否已有系統 cron／WP-CLI runner，避免重複。
Action Scheduler 的資料存在哪裡？
Action Scheduler 3.0 或以上使用 actionscheduler_ 前綴的 custom tables；3+ 會由舊 custom post type 遷移 [1]。WooCommerce 的舊說明頁仍有 CPT 說法，應以 Action Scheduler 現代文件及站點實際 data store 為準。
重跑成功後，為何仍要對帳？
因為 complete 只表示 callback 在該次執行沒有報錯，不保證付款、訂單、庫存、電郵或 webhook 的業務結果正確。重跑後仍要核對外部服務與業務物件。
資料來源
WooCommerce Developer Blog — What’s changing in Action Scheduler 4.0.0
WooCommerce Subscriptions — Failed Recurring Payment Retry System
Action Scheduler — Background Processing Job Queue for WordPress
排程積壓，先把證據與外部結果分清
Managed-WP.™ PRO 提供 WordPress 專業代管服務。若你正整理 Action Scheduler、WP-Cron、付款對帳與重跑範圍，可按實際站點、版本、外掛與權限確認支援邊界。
聯絡 Managed-WP.™ PRO若你需要按實際 WooCommerce 排程、付款與通知流程整理分流紀錄，可聯絡 Managed-WP.™ PRO。
編輯說明：本文由 Managed-WP.™ PRO 編輯團隊根據上述官方文件整理。標示為實務建議的內容不是 WordPress、WooCommerce、Action Scheduler 或付款商的功能保證；版本、介面、runner、儲存方式與供應商行為可能變更，請以實際環境及最新官方文件為準。本文沒有指示在正式站批量取消、刪除或重跑工作。