任务没跑成之后，才是真正的麻烦
错过一次，要等下一个周期
每周一次的任务在触发那一刻服务正好重启，错过了就得等到下周，这一周都用着旧设置。
重启后一半任务停在“进行中”
服务被打断，出价计算停在半路，记录显示“进行中”，却再也没有人去完成它。
一关机，失败刷屏
电脑晚上关机，每个任务都在反复失败、反复重试，第二天日志里几千条错误，真正的问题被淹没。
补做的五条规则
- 按执行窗口判断。每小时的任务看这一小时，每天、每周、每月的任务看它应当执行的那一天；到点后留出宽限时间再检查，避免把“正在启动”误判成漏跑。周任务错过了触发时刻，不用等到下周，当天窗口内就会补。
- 只认成功完成。“开始过”“部分完成”“中途被打断”都算没做成；只有成功完成的记录才会让巡检跳过它。
- 有上限、有间隔、有边界。每个窗口内补做次数有上限，两次补做之间留有间隔；正在运行的任务不补，已停用的任务不补，调度器暂停期间不补。
- 主动推迟不等于失败。因中转离线、数据暂时被占用而主动推迟的一轮，本窗口不反复补跑；中转回线后，针对这次离线专门补做一次，每次离线只补一次。
- 做到一半的接着做完。服务重启时被打断的任务会重新提交；出价计算开始前先记下这一轮的范围，进程死亡后按原范围重新提交直到成功，之后已经有成功计算的不再重复，过时的记录直接作废。
补做在界面上是透明的
未执行
应在某个时间执行却没有任何记录，任务心跳面板标为“未执行”，并提示系统将自动补做。
中断未完成
只有“开始”没有“完成”，标为“中断未完成”，显示开始时间与已补做次数。
失败
最近一次执行失败，显示失败消息；补做若干次仍未成功，会明确写出“已自动补跑 N 次仍未成功”。
补上了就不再打扰
失败之后只要同一任务有了成功完成的记录，这条提醒自动消失。
补做有记录
每一次补做都在日志里留下标记，写明它原本应在何时执行、这是第几次补做。
也可以不等
不想等巡检，可以在任务心跳面板点“立即执行”或“重新执行”，见 任务心跳监控。
任务没跑成之后：三种做法的差别
| 对比项 | 手工运营 | 通用工具 | PPCWISER 琼仁智度 |
|---|---|---|---|
| 怎么判断“做过了” | –凭记忆 | –视工具而定 | ✓只认窗口内成功完成的记录 |
| 错过触发时刻 | ✕发现了才补 | –常见做法是等下一周期 | ✓窗口内自动补做 |
| 补做的边界 | – | –视工具而定 | ✓有上限与间隔；运行中、已停用、已暂停的不补 |
| 电脑离线期间 | ✕反复失败 | –视工具而定 | ✓读取类推迟，回线后补做一次 |
| 计算做到一半 | ✕从头再来 | –视工具而定 | ✓按原范围续跑，之后已成功的不重复 |
| 补做会不会写错时段 | – | –视工具而定 | ✓分时切换按当下时刻判断 |
“视工具而定”表示我们无法替其他产品作答，请以各服务商的说明为准。
一次没跑成，不会变成一整天没跑成
窗口内补上
错过的任务在窗口内补做，不用等下一个周期，也不用你手动发现。
补做不失控
有上限、有间隔、主动推迟不反复补，不会把一次故障放大成几千条失败。
半截工作有人收尾
被打断的任务重启后重新提交，出价计算按原范围续跑直到完成。
补做不帮倒忙
分时切换按当下时刻写值，下发只补没到位的系列，补做不会写错、不会重复。
补做的是同一套结构上的同一个任务
补做不会改变任务的对象和规则：补做的否词仍按 广告结构 里各系列的角色来加，补做的下发仍以系列为单位、只推没到位的部分。结构一致，补做才和按时执行得到同样的结果。接入时选方案 A（重构正在跑的系列）或方案 B（保留原系列、另建标准结构）都适用。
关于漏跑补执行的常见问题
每周一次的任务错过了，要等下周吗？
补做会不会补出重复改价？
电脑关机一整晚，第二天会发生什么？
我暂停了调度器，恢复后会一次补很多任务吗？
补做一直不成功怎么办？
相关功能
任务不漏跑不重跑
只认“做成了”：漏跑补做、中断接续、卡住收尾、不重复启动。
查看 →离线保护关机断网不失控
离线推迟、回线补做一次、超 2 小时双向提醒，亚马逊上的设置照常生效。
查看 →任务监控任务心跳监控
心跳停滞、失败、超时、没执行，首页亮灯并写明原因，一键重新执行。
查看 →任务中心定时任务中心
总开关、单任务启停、改频率、立即执行、运行日志，全部在一个页面。
查看 →计算与下发计算与下发任务
每天一轮 SP+SB 出价计算，算完再三合一下发，低谷与高峰自动切换。
查看 →自动化任务自动化任务
全天自动运行的任务地图：同步、计算、下发、关键词、维护；漏跑会补，卡住会亮灯。
查看 →参考资料与权威来源
本页所有涉及亚马逊规则、行业数据与方法论的表述均标注来源。链接指向官方文档、同行评审论文、专利或法律法规原文；访问日期 2026-09。
- [1]论文Distributed Periodic Scheduling with Cron（Site Reliability Engineering 第 24 章） — Google SRE Book · 2016定时任务有“漏跑”和“重复执行”两类失败；许多任务不是幂等的，重复执行可能无法撤销，因此需要可靠记录任务“即将启动”和“已经完成”两个时点，才能在故障后正确恢复。
- [2]标准CronJob（Kubernetes 官方文档） — Kubernetes Documentation · 2025业界通用的定时任务控制器需要回答两个问题：错过预定时间多久以内还应补启动（超过期限就跳过本次），以及上一次还没结束时是否允许并发（可设为禁止并发，跳过新的一次）；由于调度的边界情况，同一任务可能被创建两次或一次都没有，因此任务应当设计成幂等。
- [3]官方REL05-BP03 Control and limit retry calls — AWS Well-Architected Framework · Reliability Pillar · 2026重试应采用指数退避加随机抖动并限制最大次数；过载引起的失败盲目重试只会更糟，多层叠加重试会形成重试风暴，对非幂等调用重试会产生重复结果。
- [4]官方REL05-BP01 Implement graceful degradation to transform applicable hard dependencies into soft dependencies — AWS Well-Architected Framework · Reliability Pillar · 2026依赖不可用时，组件应以降级方式继续履行核心功能，把失效视为正常运行状态；反模式包括部分失败留下不一致状态、刷新失败时清空本地状态，下游持续失败时继续重试只会加重负载。