When GitHub Actions Go Silent: Debugging Elusive Scheduled Workflow Runs
说明与用途
GitHub Actions 定时工作流因演员用户被停用和高峰期导致停止运行。解决方案:更新 cron 表达式并用活跃用户提交。
问题
A scheduled GitHub Actions workflow configured with cron: '*/15 * * * *' on the main branch was active but produced no runs, leaving the author unable to confirm if GitHub was evaluating the schedule.
结果
Scheduled workflow resumed running after re‑assigning an active actor and shifting cron times off peak load periods.
工作流
- Identify that the scheduled workflow’s actor is the last user who committed the cron line.
- If the actor’s account is deprovisioned, the schedule stops running.
- Commit a change to the cron line on the default branch with an active user to re‑establish the actor.
- Adjust the cron expression to avoid top‑of‑the‑hour times, e.g., change to
'7,22,37,52 * * * *'. - Push the updated workflow file to the main branch.
- Verify runs with
gh api "repos/OWNER/REPO/actions/runs?event=schedule&per_page=5" --jq '.workflow_runs[] | [.created_at, .name, .status]'. - If no runs appear, confirm workflow content with
gh workflow view --yamland check file location and default branch.
证据
The execution of a scheduled workflow is intrinsically linked to the user who last committed the cron line.
If this user's account is deprovisioned—a common occurrence in larger organizations or with Enterprise Managed Users (EMUs) during employee transitions—the scheduled workflow will cease to run.
GitHub's documentation explicitly states that scheduled runs "can be delayed during periods of high loads," and that "high load times include the start of every hour."
Change your cron line to something like: '7,22,37,52 * * * *'. This still runs every 15 minutes but avoids the congested :00, :15, :30, and :45 slots.
- 记录日期: 2026-11-02T02:28:52.131Z