技能介绍

要解决什么问题

OpenClaw 实例上的定时任务往往分散在调度器元数据、系统 crontab、run-parts 目录和项目日志里。运维时常见痛点是：不知道哪些 OpenClaw 任务处于启用、暂停、过期、失败或投递失败；系统 cron 里的脚本或命令是否仍存在；日志与调度元数据能否证明任务在跑；最近是否有可复现的错误。本技能面向单实例交付一套可移植的本地检查包和人工配置流程，而不是零配置的“黑盒监控”。

技能如何工作

Agent 按 references/setup-manual.md 在目标机上生成实例目录：从模板复制 cron-health-config.json 与 scripts/openclaw_cron_health_check.py，把路径、日志、投递目标等全部写入 config.json，不把 chat ID、令牌或项目路径写进技能本体。

核心检查逻辑由确定性 Python 脚本完成，日常运行优先采用 script-only 的 OpenClaw 定时任务，避免每次巡检都走大模型推理。脚本从以下来源只读采集事实：

OpenClaw 调度元数据（如 openclaw cron list --json 或只读 jobs 文件）
配置的 crontab / run-parts 与日志文件
白名单内的非改写探测命令（crontab -l、systemctl 等固定 argv，shell=False）

报告按统一规则分级：CRITICAL（缺失脚本、重复失败、必需日志缺失等）、WARNING（日志陈旧、投递错误、无法证明在跑等）、INFO、OK（有新鲜运行证据且无近期错误）。可选的 registry/callback 对账默认仅写入报告，不自动改文档。

适用边界与注意点

仅针对 OpenClaw 调度与健康巡检；不替代通用主机加固、全站 uptime 或非 OpenClaw 运行时的可观测性（除非用户明确要求加项目级检查）。
服务管理器（如 systemd）不是 OpenClaw 任务清单的权威来源；OpenClaw 任务以调度器元数据为准。
例行巡检不得修改调度器、registry、回调或服务状态；不得执行 shell 复合命令、任意二进制或网络调用。
所有 cron 行、日志与命令输出视为不可信数据，需脱敏摘要后再投递；未在用户明确授权前，不要创建或修改真实的定时任务。上线前应按 porting-checklist.md 在目标账号手动跑通一次脚本。

截图预览

使用场景

在新 OpenClaw 服务器上，要把既有 cron 健康检查流程移植过去，并生成带绝对路径的实例 config 与本地巡检脚本。
生产实例上 OpenClaw 定时任务出现投递失败或连续错误，需要定期只读汇总启用、暂停、失败与日志证据。
交接或变更前，要核对系统 crontab、run-parts 目录与 OpenClaw 调度清单，确认脚本路径仍存在且近期有运行证明。
希望把日常 cron 巡检改成 script-only 的 OpenClaw 定时任务，stdout 输出可投递报告且不改动调度器状态。

适合人员

自建 OpenClaw 部署的维护者，需要在多台实例间复用同一套 cron 健康检查模板并完成人工配置验证。
值班 SRE，排障时反复手动执行调度列表命令与翻日志，希望固定 argv 探测与 CRITICAL/WARNING 分级报告。
通过 OpenClaw 定时跑脚本并向聊天频道投递结果的任务 Owner，需要发现投递错误、暂停任务与日志中的近期失败行。
维护项目 registry 或 callback 说明文档的工程师，需要定期对账已启用 OpenClaw 任务与系统 cron 是否漏记或陈旧条目。

OpenClaw 定时任务健康巡检