cron-retry

核心用法

Cron Retry Skill 是一套与心跳检测机制紧密集成的自动化运维方案，专门用于解决定时任务（Cron Jobs）因瞬时网络问题而失败后的自动恢复问题。用户只需在 HEARTBEAT.md 中添加一段配置说明，即可让 Agent 在每次心跳周期内自动扫描所有 Cron 任务的状态，识别出因网络错误（如连接超时、DNS 解析失败、消息发送失败等）而标记为 error 的任务，并自动触发重试。

具体执行流程为：Agent 调用 cron list 获取全部任务列表，筛选出 enabled=true 且 lastStatus="error" 的任务，进一步检查 lastError 字段是否匹配预定义的网络错误模式（如 ECONNREFUSED、、ETIMEDOUT、、fetch failed 等），若符合条件则调用 cron run 重新执行该任务，并向用户报告恢复结果。

显著优点

1. 零代码集成：无需编写复杂脚本，仅通过 Markdown 配置即可启用，极大降低使用门槛。
2. 精准错误识别：内置网络错误模式库，能够区分可恢复的网络故障与不可恢复的逻辑错误，避免盲目重试。
3. 防重试循环机制：通过检查 lastRunAtMs 等状态字段，确保不会因重复检测而陷入无限重试。
4. 透明可审计：所有恢复操作均有明确报告，用户可清晰了解哪些任务被恢复、何时恢复。
5. 与现有生态融合：专为 Clawdbot 的 Cron 工具和 Heartbeat 机制设计，无缝嵌入现有工作流。

潜在缺点与局限性

1. 依赖外部心跳机制：功能完全依赖用户正确配置并运行 Heartbeat，若 Heartbeat 未启用或配置错误，自动恢复将失效。
2. 仅覆盖网络类错误：对于配置错误、权限不足、数据缺失等非网络类故障，该 Skill 明确跳过不重试，需人工介入处理。
3. 无内置退避策略：文档未提及指数退避或最大重试次数限制，极端情况下可能在网络抖动期间频繁触发重试。
4. T3 来源可信度：来自个人开发者社区，虽代码透明但缺乏企业级维护背书，长期更新与兼容性存在不确定性。

适合的目标群体

• 自动化运维工程师：需要减少因网络抖动导致的值班告警和人工介入。
• 个人开发者与小团队：使用 Clawdbot 管理定时任务，希望以最小成本提升系统稳定性。
• 消息推送类应用维护者：如 Telegram Bot、Webhook 通知等依赖外部网络的服务，网络故障频发场景。

使用风险

1. 配置依赖风险：若用户未正确理解 HEARTBEAT.md 的配置语法，可能导致检测逻辑失效或误报。
2. 状态竞争风险：在任务重试执行期间，若原任务状态被其他进程修改，可能引发状态不一致。
3. 日志膨胀风险：高频网络故障场景下，若未配合日志轮转策略，恢复报告可能产生大量日志输出。
4. 权限隐式要求：cron run 操作需要对应权限，若 Agent 权限配置不当，重试将静默失败。