Delayed or missing schedule runs despite enabled workflows and free allowance

[sternmelech-ctrl]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Schedule & Cron Jobs

Discussion Details

I have an active private repository on GitHub Free. Two enabled workflows on the default branch use schedule triggers: one every two hours and another four times daily, at minutes other than the start of the hour.

On 21 October 2026, several scheduled times passed, including 12:53 and 12:57 UTC. At 14:01 UTC, the repository-wide Actions API query with only event=schedule returned total_count: 0, and the Actions UI agreed.

Update at 21:11 UTC: three genuine schedule runs now exist, created at approximately 15:39, 17:42 and 20:22 UTC. All completed with failure because our safety checks kept the protected operation paused after monitoring became stale. A later checker has recorded the first required recovery observation; we are preserving those safeguards while awaiting another genuine automatic run. I cannot reliably associate each delayed run with its intended cron slot. The current issue is therefore delayed or missing scheduling, not a claim that no scheduled run has ever existed.

A manual checker run succeeded earlier, and subsequent pull-request CI ran successfully. The repository owner already changed the cron expressions and merged them onto the default branch. The repository is active, private, neither archived nor a fork.

At 14:05 UTC, billing showed over 1,000 included Actions minutes remaining, storage below its allowance, and $0 billable Actions usage. A repository-scoped $0 Actions budget with spending stop is intentional and must remain.

GitHub reported an Actions-related incident later today, now resolved. That overlaps part of this period but does not establish the cause of the earlier missing runs.

Is there a documented way to identify which cron slot created a delayed run, or to diagnose schedule registration/account eligibility without adding paid services? What is the supported no-cost route for GitHub to inspect prolonged gaps when manual runs work?

We need genuine automatic execution. Please do not suggest paid upgrades, removing the spending stop, publishing the repository, or sharing credentials.

[PeterYousefi]

This is actually a known behavior with GitHub Actions. According to GitHub's official documentation for the schedule event, the delay happens because scheduled workflows run on a queue that is subject to high load, and GitHub does not guarantee they will trigger at the exact minute specified.

To address your specific questions:

1. Identifying which cron slot created a delayed run
   You can map a delayed run to its intended cron slot by echoing the github.event.schedule context within your workflow. This context contains the exact cron string that triggered the run, regardless of what time it actually started.

You can add a step like this to your jobs to log the intended schedule:

YAML
steps:

• name: Log triggering schedule
  run: echo "Triggered by cron: ${{ github.event.schedule }}"
  If you have multiple schedules in the same workflow, this will definitively tell you which one is currently executing.

2. Diagnosing prolonged gaps & the no-cost support route
   Because your manual runs succeed and your billing/allowance is intact, this is almost certainly standard queue delay rather than a configuration error.

The no-cost support route: This community forum is the primary free route. You can also submit a ticket through the GitHub Support Portal, though Free tier accounts receive community-based routing or lower priority compared to Enterprise accounts.

Mitigation: You already did the best practice by moving the cron times away from the start of the hour (e.g., avoiding 0 * * * *), as top-of-the-hour slots experience the most severe throttling.

Unfortunately, there is no hidden setting to force strict timing on the Free tier; the queue delays are simply a trade-off of the shared runner infrastructure. Logging the github.event.schedule context will at least give your safety checks the exact data they need to verify which slot is running.