如何诊断失败的 cron 任务或 systemd timer？
从调度器自身证据开始，区分已证实失败与 cron 历史缺失，再核对业务结果后决定如何处理。
直接回答
诊断 systemd timer 时，应把 timer 的上次和下次触发、关联 service 结果、退出状态与有界 journal 日志作为一条证据链查看。诊断 cron 时，先确认任务定义和预测调度，再使用可归因日志，或通过备份产物、证书到期时间、心跳文件、HTTPS 健康端点等明确成功检查验证业务结果。如果 cron 没有可靠的逐任务结果，就应保持 Unknown，而不是把没有消息当作成功。
适用场景
- 备份、证书续期、报表或业务脚本可能已经停止工作。
- systemd timer 已逾期，或关联 service 返回非零退出状态。
- cron 定义仍存在，但服务器没有提供可信的逐任务结果。
分步骤复核
确认任务身份
在使用任何结果作为证据前，先核对调度来源、所有者、命令或 unit 与主机。
检查调度
查看 systemd 的上次触发和下次运行，或受支持 cron 语法的明确标注预测。
查看原生运行证据
对于 systemd，读取关联 service 的结果、退出码或信号，以及有界 journal 样本。
验证业务结果
使用已配置的产物、证书、心跳或 HTTPS 检查，确认任务是否真正完成目标。
按运行手册处理
使用任务备注和运行手册安全排查；JobLens 保持只读，不会重跑或编辑任务。
相关技术原理
Systemd 会连接调度与服务证据
timer 记录调度事实，关联 service 记录执行事实；只看其中一边可能隐藏真正的故障。
传统 cron 往往没有持久结果
crontab 只能证明调度意图，不能证明命令成功执行；只有其他可归因系统记录时，才会有逐任务退出历史。
结果检查可以补上证据缺口
新的备份产物、已续期证书、更新的心跳或健康端点，可以证明用户真正关心的结果。
恢复操作由用户掌控
JobLens 解释证据并保存任务备注和运行手册，但不会使用 sudo、修改定义或执行恢复命令。
风险与不应执行的操作
Unknown 不等于成功
缺失的 cron 证据不能被转换成绿色成功状态。
日志可能被多个任务共享
只有能够归因到所选任务与时间窗口的日志行才是有效证据。
进程成功也可能没有完成业务目标
退出码为零不能证明备份可用或证书已续期；仍需核对业务产物。
Omuuz 产品能做什么、不能做什么
能够做到
JobLens 可以盘点受支持的 systemd 与 cron 来源，连接可用运行证据，执行已配置成功检查，保留本地变化历史，并指向用户编写的运行手册。
不能做到
JobLens 不能制造缺失的 cron 退出历史，不能保证共享日志归因，不能在 Mac 关机时监控，也不会编辑、重启、启用、停用或重跑远端任务。
产品证据
