Scheduled (cron) workflow runs dropped and delayed by hours since 2026-08-26

[bproskura]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Schedule & Cron Jobs

Discussion Details

Since 2026-08-27 a schedule trigger in a private repository stopped working
reliably. Nothing was changed on our side — there were no commits in the
repository at all between Aug 23 and Aug 29.

Workflow trigger:

on:
  schedule:
    - cron: "0 7,12,16 * * *"
  workflow_dispatch:

Before 2026-08-26: 88 consecutive days, all 3 runs every single day,
each starting consistently ~40 minutes after its slot.

Since 2026-08-27: only 0–2 runs per day, at seemingly random times.
Recent examples (UTC):

Sep 08   11:58  (slot 07:00, +4h58)
Sep 08   16:25  (slot 12:00, +4h25)
Sep 09   12:08  (slot 07:00, +5h08)   -> only 1 of 3 that day

What makes this look like an event-delivery problem, not runner capacity:
in every run created_at == run_started_at to the second. The run is not
queued waiting for a runner — it is created hours late, or never.
workflow_dispatch on the same workflow starts within seconds, every time,
so Actions itself is enabled and minutes are available.

Already tried, none of it helped:

- 5 different cron times, including non-round minutes (:07, :30) to avoid
  the documented top-of-the-hour load window
- renaming the workflow file, which creates a new workflow id and re-registers
  the schedule from scratch
- disable + enable of the workflow via the REST API
- several pushes to the default branch to resync the schedule

The workflow file is on the default branch, the workflow state is active,
and the repository is active (commits almost every day).

The start of this lines up exactly with the Actions incidents on 2026-08-26
("Incident with Actions", critical, and "Incident with Actions and Pull
Requests"). The status page has shown Actions as operational ever since, so
this looks like a per-repository scheduler registration that stayed broken
after the incident rather than an ongoing platform outage.

Questions:

1. Did anyone else see scheduled workflows degrade permanently after the
   Aug 26 incident, and did it recover on its own?
2. Is there any way to force the schedule to be re-registered that we have
   not tried?

[Kushan20070126]

I have seen similar behavior with scheduled GitHub Actions, especially when the run is created late rather than waiting in the runner queue.

One useful distinction is created_at versus run_started_at. If both timestamps are almost identical, the delay happened before the workflow entered the runner queue. That points more toward the scheduled event being delivered late than runner availability.

Since workflow_dispatch works immediately, Actions itself is enabled and the runner capacity is probably not the issue.

I would also avoid relying on a schedule as the only mechanism for an important job. As a temporary workaround, you could use an external scheduler to call the workflow's workflow_dispatch endpoint.

For example:

1. Keep the existing schedule trigger.
2. Add workflow_dispatch.
3. Use an external cron service to dispatch the workflow at the required times.
4. Monitor the scheduled runs until GitHub's scheduler behavior is stable again.

The fact that changing the cron expression, renaming the workflow, toggling the workflow, and pushing to the default branch did not fix the problem makes a repository-side cron registration issue plausible.

I would also include the workflow run IDs and timestamps when reporting this to GitHub Support. Those give GitHub enough information to investigate the scheduler/event-delivery side rather than only the runner side.

[felipebridge]

Adding one more data point that's documented but easy to miss: GitHub's own Actions docs explicitly call scheduled (cron) events best-effort, not guaranteed — "the schedule event can be delayed during periods of high load of GitHub Actions workflow runs", and under sufficient load a scheduled run can be dropped entirely rather than just delayed. That's consistent with what you're seeing: created_at == run_started_at rules out a runner-queue delay, so the event itself is being generated late (or not at all) upstream of your repo.

To directly answer your two questions: there's no documented user-facing or API-level action that forces GitHub to re-register/resync a repository's cron scheduler — everything you already tried (rename, disable/enable, re-push) is the full set of things a user can do. Given the timing lines up exactly with the Aug 26 incident, this really does look like a per-repo scheduler state that got corrupted during that incident and needs a GitHub engineer to reset from their side, not something fixable from the repo. I'd escalate through support.github.com referencing the incident and pasting a few run_ids with their created_at/run_started_at pairs — that's the evidence that gets this routed to the right team fast.

In the meantime, the workaround already suggested (external scheduler hitting workflow_dispatch) is the right stopgap.

[tim32142000]

Hello,

I am seeing consistent multi-hour delays with GitHub Actions scheduled workflows.

Public repository:
https://github.com/tim32142000/fetch-stock

Workflow:
https://github.com/tim32142000/fetch-stock/blob/main/.github/workflows/fetch_stock.yml

The schedule is:

on:
schedule:
- cron: '10 6 * * 1-5'

The expected trigger time is 06:10 UTC on weekdays.

However, recent scheduled runs have been created approximately 5–6 hours late.

Examples:

Sep 17: created_at 11:33:27 UTC (+5h23m)
https://github.com/tim32142000/fetch-stock/actions/runs/35216310228

Sep 16: created_at 11:24:36 UTC (+5h15m)
https://github.com/tim32142000/fetch-stock/actions/runs/35090152600

Sep 15: created_at 11:37:25 UTC (+5h27m)
https://github.com/tim32142000/fetch-stock/actions/runs/34964280265

For these runs, created_at and run_started_at are identical to the second.

This suggests that the workflow is not waiting for a runner. The scheduled workflow run itself appears to be created several hours after the expected cron time.

The issue has occurred repeatedly since late August / early September.