GitHub Actions · schedule · Checked November 5, 2026

GitHub Actions scheduled workflows running hours late or not at all: since late August 2026, the checks on your side, and an outside trigger

Since August 26 and 27, 2026, many public reports say schedule events start hours late or create no run at all, while push and workflow_dispatch start normally. One project measured on October 28 that an hourly 17 * * * * went from about 24 runs a day to 4 to 6, and that a daily run at 06:23 UTC started between 10:42 and 15:41 UTC (knowledge-medium #1458). The longest thread, open since August 27, has no reply from GitHub staff (community discussion #206019), and the same project found no incident for scheduling on GitHub Status. GitHub's documentation says only that the event can be delayed when load is high, most of all at the start of every hour, and that some queued jobs may be dropped.

What it looks like

There is no error. The schedule runs that exist start at uneven times, and the missing ones leave nothing: no run, no log and no record in the API. For cron: "0 * * * *", the last five scheduled runs started at (#206019, September 2):

2026-09-02T06:34:35Z
2026-09-02T01:48:32Z
2026-09-01T23:38:58Z
2026-09-01T21:33:37Z
2026-09-01T18:57:33Z

Because a dropped tick leaves no trace, the run list alone cannot tell "dropped" from "never set up". The checks below rule out the causes on your side first.

Checks on your side (read only)

• List only the scheduled runs: gh run list --workflow FILE.yml --event schedule --limit 50 --json createdAt,status,conclusion. Gaps mean no run was created; runs with the conclusion cancelled between them point to the next item.
• A concurrency group allows one pending run by default. When a new run queues behind one in progress, the older pending run is cancelled. If a run takes longer than the interval, most ticks end up cancelled. queue: max lets up to 100 runs wait instead (GitHub's concurrency documentation).
• The workflow's state: gh api repos/OWNER/REPO/actions/workflows/FILE.yml --jq .state. disabled_inactivity means a public repository had no activity for 60 days, and the Actions tab says "This scheduled workflow is disabled because there hasn't been activity in this repository for at least 60 days." disabled_fork is a fork of a public repository, where schedules are off by default. gh workflow enable FILE.yml turns it back on.
• The workflow file has to be on the default branch, and the run uses the last commit there. A cron changed on another branch, or a default branch renamed, changes nothing until the file on the default branch says so.
• The cron is read in UTC unless the entry has timezone: with an IANA name, such as timezone: "Asia/Tokyo". A run that is always late by the same whole number of hours usually has a cron written in local time.
• The shortest interval is 5 minutes, and @daily, @hourly and the other shortcuts are not supported.
• GitHub suggests a minute other than 0. Since August, though, reports show runs at :17, :23 and :37 late as well, so moving the minute helps less than it used to.

When it is GitHub's scheduler

If all of that is in order and workflow_dispatch starts at once, nothing in the workflow will make the schedule punctual. For a job that has to run, start it from a clock outside GitHub and keep the schedule as a backup:

gh workflow run FILE.yml --ref main

• The REST request is POST /repos/OWNER/REPO/actions/workflows/FILE.yml/dispatches with {"ref":"main"}. A classic token needs the repo scope; a fine-grained token needs write access to Actions on that repository. The workflow needs workflow_dispatch in its on:.
• Make the job safe to run late or twice: work out what it should process from the data, not from the time it started.
• To know which slot a scheduled run belongs to, give each slot its own cron line. github.event.schedule holds the line that fired (#210111).

Telling it apart

• The run is created on time but waits with "Waiting for a runner to pick up this job": that is a runner shortage, not scheduling (waiting for a runner).
• A run stays Queued with no jobs and cannot be cancelled: when a run will not stop, and force-cancel.
• No event creates a run in one repository, push and pull requests included, while other repositories work: that is a problem with the repository or account that only GitHub Support can see (#212022).

See your workflow runs from IntelliJ IDEA

Pipeline Inbox for GitHub Actions Workflows, a plugin by Lesstep for JetBrains IDEs 2024.1 or later, lists the runs of all your repositories in an IDE tool window, with their jobs and steps, so you can see when a nightly run last started, and your current branch's runs are in the status bar. Reading is free; re-running failed jobs, cancelling, running workflows and reviewing deployments are Pro (US$1.50 a month, with a 30-day trial).

Get it on JetBrains Marketplace

GitHub and GitHub Actions are trademarks of GitHub, Inc.; IntelliJ IDEA is a trademark of JetBrains s.r.o. This page is not affiliated with, sponsored or endorsed by GitHub, Inc. or JetBrains.

More: "Waiting for a runner to pick up this job" · "Workflow does not have 'workflow_dispatch' trigger" · GitHub Actions plugins for IntelliJ IDEA compared · 日本語