The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →A GitHub Actions scheduled workflow can start late because Actions is busy, especially at the beginning of an hour. Under sufficiently high load, GitHub says some queued scheduled jobs may be dropped. A missing run can also have a configuration or repository-state cause: check that the workflow is enabled, exists on the default branch, and uses the intended cron time and timezone.
First determine what “skipped” means
Open the repository’s Actions run history and distinguish between a run that started late, no run that was created, and a run that exists but whose job or step did not execute. GitHub’s documentation describes load-related delays and possible dropped queued schedule jobs; it does not establish that every missing run has that cause.
GitHub’s troubleshooting guide says, “Scheduled events can be delayed during periods of high loads of GitHub Actions workflow runs.” Its events reference identifies the start of every hour as a high-load time and says that, when load is sufficiently high, some queued jobs may be dropped. GitHub does not publish a delay distribution, drop rate, or maximum lateness in the cited documentation.
Check the workflow and repository conditions
Confirm the workflow is on the default branch
The workflow file must be present on the repository’s current default branch for a schedule event to trigger. Scheduled workflows run only on that branch. A copy of the workflow on another branch will not make the schedule run there. See GitHub’s schedule event documentation.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →#1 Best Overall
Make sure the workflow is enabled
Check whether the scheduled workflow was manually disabled. A disabled workflow will not run on its schedule; GitHub’s workflow troubleshooting guidance lists this as a condition to verify.
Check for inactivity in a public repository
GitHub automatically disables scheduled workflows in public repositories when there has been no repository activity for 60 days. If the workflow stopped after an inactive period, check whether this condition applies before changing the cron expression. This inactivity rule is documented for public repositories.
Validate the cron expression and timezone
GitHub Actions uses POSIX cron expressions for schedule. By default, the expression is interpreted in UTC. GitHub also supports an optional IANA timezone, so verify the timezone configured for the schedule rather than assuming it follows the repository owner’s local time. GitHub documents a shortest scheduled interval of once every five minutes; a more frequent schedule is not supported.
For a timezone that observes daylight saving time, a scheduled time can be affected by the clock change. If the chosen time falls in the hour skipped when clocks move forward, GitHub advances it to the next valid time; its example moves 2:30 a.m. to 3:00 a.m. Review the schedule syntax and timezone behavior in GitHub’s schedule event reference.
Free tools Windows power users keep installed
One-click scans. No signup required.
Reduce late starts near the top of the hour
If a run is present but begins late, check whether its cron minute is 0. GitHub identifies the start of each hour as a high-load period and recommends choosing a different minute to reduce the chance of delay. For example, distribute work across other minutes rather than scheduling every workflow at minute 0. This lowers risk; it does not guarantee a start at the exact cron minute.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Check the associated actor in Enterprise Managed User setups
This check applies only if the organization uses Enterprise Managed Users. GitHub says scheduled runs do not happen in the documented case where the associated actor has been deprovisioned by the identity provider. Changes to the default branch or to the cron schedule can also change the actor associated with later runs. Check the actor’s account status and the applicable Enterprise Managed Users documentation.
Quick Recap
Use this diagnostic order
- Inspect Actions history: decide whether the run was late, never created, or created but did not execute the expected job or step.
- Verify repository conditions: confirm the workflow file is on the current default branch and the workflow is enabled; for a public repository, check for 60 days without activity.
- Recheck the schedule: parse the cron expression, confirm UTC or the configured IANA timezone, and account for daylight-saving transitions.
- For late runs, change the minute: avoid the start of the hour to reduce exposure to a documented high-load period, without assuming an exact start-time guarantee.
- For Enterprise Managed Users only: check whether the associated actor remains provisioned by the identity provider.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
