cron 写的是 06:00，GitHub 11:50 才跑：cronlag 帮你把延迟和漏跑一格一格算清楚
2026 年 8 月底以来，很多仓库的 on: schedule 定时工作流晚几个小时才触发，甚至直接不触发。社区讨论（#206019、#210037）里大家都在手工整理同一张表：哪些时刻跑了、晚了多久、哪些没跑、到底是不是自己的问题。cronlag 把这张表自动算出来。
真实数据
| 工作流 | cron | 结果 |
|---|---|---|
robhunter/agentdeals reverify.yml | 0 6 * * * | LATE：中位延迟 6 小时 37 分，6 次里 0 次在 1 小时内 |
| fpgas-online e2e | 0 */2 * * * | DROPPING：3 天 36 个时刻里 24 个从没跑过 |
| kort0881 facts generator | 每天多次 | DROPPING：50 个漏掉 17 个，中位延迟 2 小时 39 分 |
为什么难看出来
REST API 只列出 schedule 触发的运行，不告诉你它对应哪个 cron 时刻。要算延迟，得按 GitHub 的规则展开 cron（5 段、月份/星期名称、日和星期的“或”规则、2026 年新增的 timezone: 和夏令时空档），再把每次运行归到对应时刻。如果你上周二改过 cron，一半“漏跑”其实根本不存在。
cronlag 会读工作流文件的提交历史，按当时生效的 cron 判断；每次运行归到 24 小时内最近的、还没被占用的时刻；延迟量的是“时刻 → 运行创建”。创建发生在任何 runner 介入之前，所以这段延迟属于 GitHub 调度器；排队时间（创建 → 开始）单独显示，那才和你的 runner 有关。
是我的问题还是 GitHub 的？
逐项检查：公开仓库 60 天无活动被禁用（第 45 天起提醒）、手动禁用、仓库归档、YAML 解析失败、cron 不合法、间隔小于 5 分钟、整点 0 分（并推荐一个更空闲的分钟）、fork、定时任务不在默认分支、没有 workflow_dispatch、runner 排队。都没问题、手动运行几秒就启动，它会直接告诉你：延迟在调度器那边。
补跑但不重复跑
在任意非 GitHub 的 cron 里每 10–15 分钟执行 cronlag catchup owner/repo --dispatch，对超过 15 分钟宽限期仍没运行的最新时刻触发一次 workflow_dispatch。GitHub 迟到的那次运行来了以后，Action 的 mode: guard 发现这个时刻已经被补跑覆盖，输出 skip=true，不会跑两遍。
npx github:Blackman99/cronlag owner/repo
npx github:Blackman99/cronlag catchup owner/repo --dispatch另外还有 --format markdown（直接贴进 issue）、--fail-on dropped（CI 里每周体检）和 MCP 服务器 cronlag mcp（让 AI 助手用真实数据回答“为什么昨晚的任务没跑”）。也可以在浏览器里直接查一个仓库，请求从你自己的浏览器发往公开 API。
github.com/Blackman99/cronlag · MIT 协议