Repository navigation
Retry and sweep crons run every 4–8 hours instead of every 2 h / 15 min, while PR comments promise specific retry times #2170
Description
Problem
The time-based backstops run far less often than their cron expressions say, while agent comments on PRs promise specific retry times. Combined with long Actions queue waits, a PR that depends on a timer rather than an event can sit for most of a working day.
Evidence
Scheduled runs actually recorded (from gh run list --event schedule):
| Workflow | Cron | Scheduled runs observed |
|---|---|---|
dev-lead-retry.yml |
15 */2 * * * (every 2 h) |
10-07 23:03, 10-08 06:00, 13:25, 19:56, 10-09 00:21, 09:00, 16:58, 22:36 — gaps of 4.4 to 8.6 hours |
pr-review-sweep.yml |
2,17,32,47 * * * * (every 15 min) |
10-08 01:20, 07:56, 15:29, 20:47, 10-09 01:08, 07:26, 14:33, 19:50 — gaps of 4.3 to 7.5 hours |
Meanwhile, on 2026-10-09 in petry-projects/empower-personal-dashboard:
- dev-lead posted "The retry cron will re-attempt automatically. Next attempt after: 17:36:27Z" on #65 and "…17:34:57Z" on #67. No retry ran on either until a manual re-run of a check at 19:29 produced an event.
- pr-review posted "pr-review-sweep will re-review this PR after 17:08:18Z" on Compliance: non-stub-claude.yml #65 and "…17:29:31Z" on Compliance: agents-md-missing-org-ref #67. No re-review followed.
Actions queue waits the same day (run created to first job started):
| Run | Created | Started | Wait |
|---|---|---|---|
| PR Review — Mention Trigger 37984440634 | 20:03:49 | 20:11:34 | 7m45s |
| PR Review Agent — Trigger 37985324196 | 20:11:40 | 20:24:51 | 13m11s |
| PR Review Agent — Trigger 37993777221 | 21:29:41 | 21:48:13 | 18m32s |
| PR Review Agent — Trigger 37996091545 | 21:53:11 | 22:04:56 | 11m45s |
Why it matters
Several gaps today had no event to close them and so depended on these timers: a required check left red after a since-fixed external cause, a rate-limit deferral whose reset had passed, and a bot comment waiting on a retry. Each stayed stuck until someone re-triggered it by hand.
Suggested acceptance criteria
- Retry and sweep cadence is measured (scheduled runs per day against the cron's nominal count) and reported in the existing health report.
- Agent comments stop promising a specific retry time unless something other than a GitHub
scheduletrigger guarantees it, or the promised time is stated as "not before". - Consider an external or self-rescheduling trigger for the two backstops, since GitHub's
scheduleevent is best-effort.
Related: #1741, #1864, #1863, #1402.
Filed from a Claude Code session driving petry-projects/empower-personal-dashboard issues 51–53 on 2026-10-09, at the maintainer's request. All times UTC.
Activity
github-actions commentedon Oct 9, 2026
Thank you for the detailed report and the run-by-run evidence; it makes the gap between the cron schedules and the retry times promised in PR comments easy to see. To help us scope the fix, can you tell us whether the sparse scheduled runs also appear in other repositories' workflows on the same cron cadence, or only in
dev-lead-retry.ymlandpr-review-sweep.yml? That would show whether this is GitHub's best-effortschedulethrottling or something specific to these two workflows.