When a GitHub Actions workflow executes normally via workflow_dispatch (manual trigger) but never runs automatically via schedule: (cron), it is almost always caused by one of three core GitHub Actions requirements:

1. The Workflow File is NOT on the Repository's Default Branch (Most Common)

GitHub Actions only evaluates and registers scheduled cron jobs from the default branch (typically main or master).

• Why manual dispatch works: When you trigger workflow_dispatch manually from the GitHub UI, Actions lets you select any branch in the repository dropdown, so it runs successfully on feature branches.
• Why schedule fails: GitHub's internal cron scheduler searches only .github/workflows/ on your repository's default branch. If the workflow file exists only in a feature branch, staging branch, or PR branch, the scheduled event will never be queued.
• Fix: Merge or push your workflow YAML directly into your default branch (main).

2. The 60-Day Inactivity Auto-Disable Rule

GitHub automatically disables scheduled workflows to save compute resources if there has been no commit or activity in the repository for 60 consecutive days.

• How to verify: Navigate to Actions -> select your specific workflow in the left sidebar. If it was suspended due to inactivity, you will see a yellow banner:

  "Scheduled workflows have been suspended due to repository inactivity."

• Fix: Click the Enable workflow button on that banner, or push a new commit to the repository. Note that manual workflow_dispatch still works even while scheduled runs are suspended, which often causes confusion.

3. UTC Evaluation vs. Local Timezone

GitHub cron syntax is strictly evaluated in UTC (Coordinated Universal Time).

on:
  schedule:
    # Runs at 08:00 UTC, NOT your local time!
    - cron: '0 8 * * *'

If you configured the cron expecting your local timezone (e.g., UTC-5, UTC+5:30), the scheduled run may be scheduled hours ahead or behind your expected window.

4. Peak-Hour Scheduling Delays (Top-of-the-Hour Latency)

GitHub Actions runners experience massive spikes in scheduled jobs at the top of the hour (:00 or :30). During high-load periods, GitHub officially notes that scheduled runs can be delayed by 15 to 45+ minutes.

• Fix: Stagger your cron expression to an unusual, off-peak minute (e.g. 17 3 * * * instead of 0 3 * * *).

5. Forked Repository Setting

If your repository is a fork, GitHub disables scheduled workflows by default for security reasons.

• Fix: Go to your fork's Actions tab and click "I understand my workflows, go ahead and enable them".

Summary Checklist

1. Ensure .github/workflows/<your-workflow>.yml is merged into main.
2. Check the workflow page in the Actions tab to ensure it is not disabled.
3. Verify your cron schedule against UTC time.

If this resolved the issue and got your scheduled runs triggering, please mark this as the accepted answer so others in the community running into scheduled workflow delays can find it!

one more cause to rule out after the default branch: a schedule on a repo with no activity for 60 days gets disabled automatically and the actions tab shows a banner to enable it again. also check that the cron line is valid and in UTC.

if the job matters, don't rely on schedule alone. github says scheduled runs can be delayed or dropped when load is high. trigger it from an outside cron with workflow_dispatch and put a dead man's switch on it so you hear about a run that never happened.

Two things the thread doesn't cover yet. First, GitHub's docs say schedule runs can be delayed under load, with the start of every hour named as a high-load time, and some queued runs may be dropped. So avoid minute 0, and note the shortest interval is 5 minutes. Second, to see what GitHub registered, run gh api "repos/OWNER/REPO/actions/workflows/FILE.yml/runs" --jq '.workflow_runs[] | select(.event=="schedule") | .created_at' and compare it with your cron times. If it is empty and the repo is public, check whether the schedule was disabled after 60 days of inactivity. The docs say a commit by someone with write access that changes the cron: line reactivates it, and gh workflow enable FILE.yml also works. Post your on: block if it still doesn't fire.