Action Scheduler中持续出现失败任务，应先按hook、时间和日志找出同一类失败，再处理原因。任务数量多不一定就是故障；把失败记录全部删除，也不会自动修复未来执行。
先区分任务状态
待处理、执行中、完成、失败和取消表示不同阶段。待处理任务要结合计划时间判断是否逾期，不能只看数量。失败记录则应打开查看具体错误及执行历史。
记录hook、所属组件、计划时间和错误内容。参数可能含订单或个人数据，不应直接公开。
判断是调度问题还是任务本身问题
如果多种hook同时长时间不执行，检查WP-Cron、回环请求、主机资源和队列运行机制。如果只有一种hook反复失败，优先检查对应插件、外部接口或数据。
任务执行中超时与完全没有启动，需要不同处理。结合PHP错误和服务器日志，避免仅靠队列列表猜测。
不要直接批量运行全部失败任务
邮件、库存同步、订阅或支付相关任务可能产生外部影响。先确认任务是否可以安全重试、是否幂等，以及是否已经部分执行。
在测试环境或小范围内验证根因修复后，再按组件支持的方式重试具体任务。对于失效的旧任务，应理解业务含义后再取消或清理，保留必要审计信息。
队列积压如何处理
检查新任务产生速度是否超过处理能力，是否存在重复创建或失败重试循环。适当调整批处理能力需要结合主机资源，不能单纯提高并发把数据库压满。
长期保留策略应按工具支持方式设置，但清理历史记录与恢复业务执行应分开判断。
验收看新任务和旧业务
确认新任务能按预期完成，失败不再持续增加，并核对受影响的订单、通知或同步结果。历史失败记录仍存在，不一定代表修复无效；关键是它们是否已被妥善处理和记录。
点击Run成功一次就够了吗？ 还要观察自动调度是否恢复，以及后续同类任务是否稳定执行，避免只修好了手动执行路径。
参考资料
相关问题
本文为通用排查指南，依据所列官方资料整理；菜单名称和行为可能随版本及主机环境变化。配图为AI生成的概念示意，不是实际故障截图。
