GitHub Actions Scheduled Workflow Not Running on Time

A scheduled workflow fires late, skips runs, or never starts because the cron expression is wrong, you assumed local time instead of UTC, the workflow is not on the default branch, or GitHub disabled it after repo inactivity.

What this error means

A workflow with on.schedule does not run when expected - it lags by many minutes during peak load, runs at the wrong hour, or stops firing entirely after the repository sees no recent activity.

on:
  schedule:
    - cron: '0 9 * * *'   # 09:00 UTC, NOT your local 9am; may also run late under load

Common causes

Cron is UTC and best-effort

Schedule cron is evaluated in UTC, not your timezone, and is not guaranteed to run at the exact minute - high load can delay or, rarely, drop a run at popular times like the top of the hour.

Workflow not on the default branch

on.schedule only runs from the workflow file as it exists on the default branch. A schedule added on a feature branch never fires.

Disabled after inactivity or bad syntax

GitHub disables scheduled workflows in repos with no recent activity (commits), and an invalid five-field cron expression is rejected so nothing is scheduled.

How to fix it

Use a valid UTC cron and offset times

Write a correct five-field expression in UTC, and avoid the exact top of the hour to reduce contention.

on:
  schedule:
    - cron: '7 13 * * 1-5'   # 13:07 UTC weekdays - offset minute, explicit days

Keep it on the default branch and active

1. Merge scheduled workflows to the default branch - they do not run from other branches.
2. Re-enable a schedule disabled after 60 days of inactivity from the Actions tab, and push activity to keep it alive.
3. Validate the cron with a cron checker; all five fields are required.

How to prevent it

• Always write schedule cron in UTC and document the local equivalent.
• Keep scheduled workflows on the default branch.
• Expect minute-level delays; do not rely on exact-time execution.

Related guides