GitHub Actions Scheduled Workflow Not Triggering: Causes and Fixes

A schedule trigger only fires when the workflow file exists on the repository’s default branch and the cron expression is valid. Check those two things first. If both are correct, the cause is usually a disabled workflow, a fork, or a delayed run.

Confirm the workflow is on the default branch

Scheduled workflows run only from the latest commit on the default branch. A schedule block on a feature branch is ignored, even if the cron is correct.

gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name'
git fetch origin
git show origin/main:.github/workflows/scheduled.yml

Replace main with the name the first command prints. If git show fails with exists on disk, but not in 'origin/main', merge the workflow into the default branch.

Validate the cron expression

GitHub uses POSIX cron with five fields, and the time is always UTC.

name: Scheduled Check

on:
  schedule:
    - cron: '30 4 * * 1-5'   # 04:30 UTC, Monday to Friday
  workflow_dispatch:

jobs:
  run:
    runs-on: ubuntu-latest
    steps:
      - run: echo "Scheduled run"

Quote the expression. Add workflow_dispatch so you can test the job body without waiting for the schedule. Note that a manual run does not prove the schedule works.

Field	Allowed values
minute	0-59
hour	0-23
day of month	1-31
month	1-12 or JAN-DEC
day of week	0-6 or SUN-SAT

Common mistakes:

• Expecting local time. 0 9 * * * is 09:00 UTC, not 09:00 where you live.
• Using Quartz-style tokens such as ?, L or a seconds field. They are not supported.
• Setting an interval under 5 minutes. The shortest supported interval is every 5 minutes.
• Putting the schedule event under a misindented on: key, which makes the workflow invalid.

If the YAML is invalid, the workflow shows an error in the Actions tab and never runs. Open the file in the GitHub web editor or run actionlint locally to find the problem. For a related walkthrough, see GitHub Actions Cache Not Working: Causes and Fixes.

Check whether the workflow was disabled

In public repositories, GitHub automatically disables scheduled workflows after 60 days without repository activity. The Actions tab then shows a banner saying the workflow was disabled. Click Enable workflow, or push a commit, to re-enable it. For a related walkthrough, see Fix ‘Resource not accessible by integration’ (403) in GitHub Actions.

Also check these:

• Forks: scheduled workflows are disabled by default on forks. Enable them in the fork’s Actions tab.
• Actions turned off: under Settings → Actions → General, make sure Actions are allowed for the repository.
• Organization policy: an org can restrict which workflows and actions run.

Allow for delays

Scheduled runs can start late, especially at the top of the hour when load is high. Delays of several minutes are normal, and under heavy load a run can occasionally be dropped. Avoid 0 as the minute for jobs that are not time-critical. Use something like 17 2 * * * instead of 0 2 * * *.

Check run history with the gh CLI

Filter by event to see whether the schedule has ever fired.

gh workflow list
gh run list --workflow scheduled.yml --event schedule --limit 10

If the list is empty, GitHub has never triggered the schedule. Fix the default branch, cron or disabled state above. If runs appear but fail, open one with gh run view <run_id> --log-failed and debug the job itself.

Debugging checklist

1. Confirm the file is in .github/workflows/ with a .yml or .yaml extension.
2. Confirm it is merged into the default branch.
3. Confirm the cron is quoted, has five fields and is written in UTC.
4. Look for a “disabled” banner in the Actions tab.
5. Check that the repository is not a fork with Actions disabled.
6. Wait at least 15 minutes past the scheduled time before concluding the run was skipped.
7. After editing the cron, commit to the default branch. A schedule change takes effect only once it lands there.