Hourly Actions schedule produced one event across eight elapsed opportunities

[vbhops]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Schedule & Cron Jobs

Discussion Details

We have a private repository on a GitHub Free organization. A workflow on the default branch uses 17 * * * * and workflow_dispatch. The repository and Actions are enabled; the workflow is active, and the author is active.

On September22,2026, the workflow was merged at12:23UTC. At20:30UTC, the workflow-runs API showed one schedule event, created17:39UTC and completed successfully. Eight hourly opportunities from13:17 through20:17 had elapsed. Manual execution had already succeeded. We have not changed the schedule or issued extra dispatches to compensate.

The organization blocks paid Actions usage with a$0 budget; reported usage was below the included monthly allowance. We understand schedules can be delayed or dropped, but have no evidence identifying the cause here.

Is there another documented prerequisite or a read-only diagnostic for such sparse schedule events, without triggering extra runs, changing permissions or raising the spending limit?

[djburneo]

Hi.
GitHub's cron scheduling often has delays or drops runs on free plans due to infrastructure load. Check if your workflow was fully active on the default branch during those 8 hours, as schedules sometimes need a full cycle to start after being deployed.
Hopefully this helps! :D

[WilliamK112]

From the conditions you listed, I do not see another documented prerequisite that would explain seven missing schedule events:

• the workflow is on the default branch;
• the workflow is active;
• workflow_dispatch succeeds;
• the cron expression is valid and uses UTC;
• minute 17 already avoids the busiest start-of-hour window.

GitHub explicitly documents scheduled workflows as best-effort: scheduled events can be delayed during high load, and sufficiently high load can cause queued jobs to be dropped. See: https://docs.github.com/en/actions/how-tos/troubleshoot-workflows#triggering-event-conditions

Unfortunately, there is an important diagnostic limitation: if the scheduler never creates a workflow run, there is no run object for the Actions Runs API to return. The API can prove which schedule runs were created, but it cannot list each missed cron opportunity as a failed or skipped event.

The useful read-only checks are therefore:

1. Query runs filtered to event=schedule and record their created_at, run_started_at, and conclusion.
2. Check the workflow file history on the default branch to prove when the schedule first became present there.
3. Check the repository or organization audit log for workflow disable/enable events, default-branch changes, or policy changes.
4. Check included Actions usage and billing state. A $0 paid-usage budget is worth documenting, but if included allowance remains and manual runs still work, it would not explain only scheduled triggers disappearing.
5. Check GitHub Status for Actions incidents covering the missing UTC windows.

Because the workflow was merged at 12:23 UTC, 13:17 was the first eligible occurrence. A single run created at 17:39 demonstrates that GitHub recognized the schedule, but the long delay plus missing occurrences is consistent with scheduler-side delay/drop rather than YAML syntax or branch placement.

If this continues for another day, I would send GitHub Support the workflow URL, the workflow file commit SHA, the exact expected UTC timestamps, and the one observed run ID. There is no safe client-side command that can reconstruct scheduler events that GitHub never materialized.

[canodvalecv30]

S