WooCommerce 计划任务失败或积压，能直接重跑吗？

计划任务就是网站安排在后台做的待办，例如给订阅续费、同步商品或发送通知。Action Scheduler 是安排和执行这些待办的工具。列表里的 Pending 是等待，Failed 是这次执行留下失败记录，Complete 是任务被标为完成；这些标签都不能代替打开订单、支付平台或收件箱看结果。

通常在 WooCommerce → 状态 → Scheduled Actions（计划任务），也可能在 工具 → Scheduled Actions 找到列表。官方后台说明介绍了查找、筛选和日志。封面左侧是一条任务记录，右侧区分到期等待与失败恢复：先查同一笔业务，不能把失败直接连到“再做一次”。

先找一条与你这次问题有关的待办

从当前故障选起，例如订阅到了续费时间却没更新，或某件商品一直没同步。打开相关任务行和日志，保留任务编号、动作名称、参数、分组、状态、计划时间与最后错误。

这些字段可以用一条教学记录解释：任务编号5172是这次执行；hook 是动作名称，帮助维护者找它调用哪个处理；args 是参数，可能带订阅640或商品编号，告诉你要打开哪笔业务；group 是分组，用来缩小列表范围。任务编号与订阅编号不同，一个找待办，一个找真实订阅，两个都留。

同时保存查看时间、后台时区、Woo与相关插件版本，以及实际加载的Action Scheduler版本。网站可能有多个插件附带它，维护者要确认实际用哪份。近期更新插件或调整主机的日期，也能帮助找故障起点。

普通运营看不到日志或参数，就请管理员提供这条记录。交外部支持时保留时间、错误和关联编号，去掉密钥、令牌与无关客户资料。为了取日志，不必先装另一套调度工具；几个月前的失败记录也不应挤掉这次影响订单的问题。

Pending 先比时间，再看原任务有没有推进

把计划时间与当前时间换成同一个时区。“明天执行”的待办今天Pending很正常；“已经逾期”则要继续看它有没有开始，以及同类任务是不是也停了。把“几小时前”展开成具体日期和时间，交接更清楚。

当前记录	下一步
Pending，时间未到	等到期后看同一编号，不提前点Run
Pending，时间已过	查新开始日志、原任务是否推进，以及其他动作是否也逾期
Failed，异常或超时	读错误，并查订单或外部服务已经做了哪一步
Complete，业务却没结果	继续查订单、接收系统或邮件，不能只看标签

逾期不一定就是WP-Cron坏了。WP-Cron是WordPress触发定时工作的机制，Action Scheduler管理这里的待办。官方FAQ说明，默认可由WP-Cron及后台请求触发，少量逾期也会出现。

保持相同筛选，过一段适合这类业务的时间，再比较原来的任务编号，而不只看总数量。例如教学观察：10:20有20条到期Pending；10:30原来的6条完成，又新增4条到期待办，因此剩18条。列表只少2，实际完成6，说明它在处理；是否赶得上店铺业务，还要看耗时和新增速度。

如果所有动作都没有新的开始日志，请维护者查触发入口、网站能否向自己发请求和主机执行环境。可参考WordPress 定时发布与WP-Cron排查，里面的文章补发方法不能直接拿来处理付款。

若别的动作正常，只有一个动作名称反复报同样错误，先查负责插件和它连接的服务。维护者可以继续找该动作调用的函数，即技术上说的回调。一个任务成功不能排除间歇故障；观察间隔也不是所有业务通用的“十分钟合格线”。

失败之后，先看钱、通知或同步有没有发生

先让维护者确认负责插件。动作名称、分组和参数是线索，还需与安装组件、文档或代码对应。其他插件和自定义代码也能把待办放进Action Scheduler，出现在Woo状态页不代表全由Woo核心创建。

按具体动作打开结果：付款查同一订单或订阅的备注及支付交易；库存同步查同一货号在接收系统里的数量；Webhook通知查同一事件有没有被对方接收并执行。Webhook是网站向另一系统发送的业务通知。

例如发送端超时，但仓库已经按那次通知建了发货单，重新发送就可能重复处理。对方结果拿不到时，先写“接收结果待确认”，找负责连接的人核，不把超时直接等同“没发生”。

WooCommerce Subscriptions 错误指南专门区分续费付款前和付款后失败，要求检查续费订单与网关是否实际扣款。钱已收、订单没更新，处理的是后续订单状态，不应因Failed再收一笔。

邮件同样分开看。Complete仍要查是否尝试发送、服务商处理及实际收件，可继续按Woo订单邮件排查查同一个订单；不为补邮件随意改订单状态。

恢复前还要看有没有新的重试任务、自动重试或另一进程正在处理同一业务。负责插件不清楚、外部结果未知、任务仍进行中时，暂不人工重跑。先确认插件怎样防止重复收费、通知或发货，再选择它支持的恢复入口。

一笔50美元续费失败，先查这50美元

沿教学任务5172走完整个判断。它的动作名称是 woocommerce_scheduled_subscription_payment，关联订阅640，本次续费订单731应收50美元。编号、金额和时间都用于教学，不是本站商店日志。

打开任务记失败时间，再打开订阅640，从备注找到续费订单731。到支付后台用原交易对应订单、金额和币种，不拿当天另一笔成功付款充当结果。本例时间线如下：

1. 10:00生成续费订单731，应收50美元。
2. 10:00:08，对应交易显示captured，即这50美元已经扣取。
3. 10:00:10后，订单更新等后续处理异常，任务5172稍后标为Failed。
4. 10:06，Woo订单还没进入应有的已付款状态，订阅也未完成同步。

现在的动作是停止重复收费，把50美元原交易、订单731备注、订阅640与任务错误交给订阅和支付维护者。维护者先修具体错误，再按该版本的Subscriptions官方流程处理付款之后的状态，使订单和订阅与这笔已付款相符。

运营不要只为消掉红色记录，把订单改成Completed。状态变动可能再发邮件、扣库存或通知仓库，需要结合插件和支付方式处理。资金记录已经确认，不应再次触发收款来“补”订单显示。

处理后回订单731，看付款与备注是否正确，订阅是否回到这次续费应有的状态；支付平台这次只应有一笔50美元收款，通知与履约也没有重复。原失败日志可以保留，当前业务结果修好，不要求为了清掉历史Failed而再做一次动作。

如果支付结果还没取得，就留“扣款待确认，暂不补扣”。如果已经确认没有扣款，先找自动重试和新续费订单，再按扩展支持的付款前恢复方法处理。付款后协调不能照搬到没付款的情况，其他订阅插件也应使用各自流程。

修好原因后，只处理一条，再看自动执行

凭据失效就修这项连接，插件函数异常就查对应版本和代码，各种动作不启动则查执行入口。先记录这次改了什么、时间，再看同一种错误是否消失。多项配置一起变，会让原因难以判断。

准备恢复一条待办前，确认业务仍需执行，没有已完成却未回写的外部结果，也没有别的进程或自动重试在做。备份能恢复网站文件和数据库，却不能撤回外部已经扣的钱或发出的货；这些仍要查真实记录。

符合恢复条件的Pending可用该行 Run，点击前刷新，确认没刚被另一个进程接走。Failed的恢复按负责插件和安装版本操作，可能在订单或订阅页面，也可能创建新任务，不一定有通用“重试失败”按钮。产生新任务时，保留旧编号、新编号与同一业务编号。

有SSH权限的维护者使用CLI前，先确认目标站点、命令版本和范围。Action Scheduler 的WP-CLI文档提醒，按hook或group拆开执行，可能改变原有时间顺序。筛出一组并不意味着这一组都能安全重做，不直接跑全队列或强制并发来处理一笔问题。

恢复后看三件事：这次原任务或替代任务有没有新日志、旧错误是否再出现；对应订单或接收方是不是实际得到结果；下一条正常产生的同类任务，能否在业务允许时间内自动完成。当前订单人工修好与自动处理恢复，要分别确认。

第一条又报相同错误，就停止扩大范围，把新日志给插件或主机维护者。下一条还没到期，就记等待到期观察，不提前执行付款来凑结果。没有SSH的运营也能提供前后两次任务记录、错误、版本和订单外部结果，完成清楚的交接。

删除Pending会取消未做的待办，清除Failed只清记录，不会补做业务。若问题反复影响店铺，可以带网站地址、相关插件名称和这条任务的脱敏错误联系跨境YOUNG，讨论维护范围；先按实际交易处理当前订单。