Why Your GitHub Actions Cron Runs Late, or Not at All

runs it at most once every five minutes;
may run it late when it is busy, most of all at the start of every hour;
may even drop it under heavy load;
only runs it from the default branch;
switches it off in public repositories after 60 days without activity.

Pick an odd minute, keep the workflow on the default branch, and do not use it for anything that must happen at an exact second.

The schedule you wrote is not the schedule you get

You write cron: "0 * * * *" and expect a run every hour, on the hour. Most of the time you get one. Some hours it starts several minutes late. Now and then it does not come at all. Nothing is broken; this is documented behaviour.

Here is the path a scheduled run takes, and where it can slip:

From cron line to running job

1. Your cron line. Five fields, read in UTC unless you add a timezone. The shortest interval GitHub will honour is five minutes.

1 / 6

Small changes that help

Avoid minute 0. GitHub itself suggests scheduling at a different time of the hour to reduce delays. 17 * * * * is just as hourly as 0 * * * *, and much less crowded.
Do not schedule more often than every five minutes. A cron line like */2 * * * * will not run that often.
Say which time zone you mean. GitHub now accepts a timezone next to cron, with an IANA time zone name such as Asia/Kolkata. Without it, the schedule is UTC:

yaml

on:
  schedule:
    - cron: "30 9 * * 1-5"
      timezone: "Asia/Kolkata"

With a time zone that observes daylight saving, a run that falls in the skipped spring-forward hour moves to the next valid time.

Keep public repositories alive, or re-enable the workflow from the Actions tab when GitHub turns it off.
Make the job safe to run late, or to be skipped. Anything that must happen at an exact time, or every time, needs a different trigger or a check inside the job.

Check an expression before you trust it

The cron expression explainer reads any five-field line, lists its next runs, and now warns when it would fire more often than GitHub allows or lands on the busiest minute. If a workflow passes locally and fails in CI for other reasons, this troubleshooting page walks through the usual causes.