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