Actions schedule events created over 5 hours after the last permitted UTC cron time (October 2, 2026)

[Rors-Box]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Schedule & Cron Jobs

Discussion Details

I need help investigating delayed or missing GitHub Actions schedule events in a private repository. Manual runs and push-triggered jobs succeed. The default branch is main, and both scheduled workflows were reported active by the authenticated API. The repository is not archived or disabled.

An independent diagnostic uses this UTC schedule, with no timezone field:

on:
  push:
    branches: [main]
    paths: ['.github/workflows/schedule-check.yml']
  schedule:
    - cron: '2-57/5 2-4 2 10 *'
permissions: {}
jobs:
  check:
    runs-on: ubuntu-latest
    timeout-minutes: 1
    steps:
      - run: date -u

The push run succeeded on October 2 at 02:42 UTC. The last permitted scheduled time that day was 04:57 UTC. However, the only schedule run was created at 09:59:38 UTC, at least 5 hours 2 minutes 38 seconds after that last permitted time. Its job started at 09:59:42 UTC, only 4 seconds after creation. This is not a rerun: run_attempt is 1.

The real reminder has cron 57 8-20 * * *, timezone Asia/Shanghai. Its two scheduled runs were:

Created (UTC)	Job started (UTC)	Result
October 2, 10:10:17	October 2, 10:10:21	Delivery request accepted at 10:10:23; user received it
October 2, 16:25:24	October 2, 16:25:48	Script skipped delivery because local time was already October 3, 00:25

At approximately October 3, 04:31 UTC, the authenticated API returned only these 3 schedule runs in total across both workflows. The reminder file's blob SHA is unchanged from October 1, and all three runs use the same default-branch commit. No new repository commit occurred when scheduling began working intermittently.

A disable/enable cycle was attempted on October 2. Its exact time is not recorded, so I cannot attribute the later runs to that operation. Earlier billing screenshots showed only 4 Linux minutes used and a billed amount of $0; no quota-exhaustion warning was shown. GitHub Status has no reported October 2–3 incident.

I understand that schedules may be delayed or dropped, and the API does not identify which intended occurrence each late run corresponds to. The UTC diagnostic's creation timestamp nevertheless shows a delay before run creation, not a five-hour wait for a hosted runner.

Could GitHub staff investigate the scheduled-event registration/delivery for this account or repository, including whether events are being dropped or throttled? Is there a supported way to resynchronize the scheduler? I can provide private repository identifiers and exact run URLs through a private support channel. I have omitted them from this public report.

[xop01]

That 09:59 UTC run is a late schedule, not a rerun. run_attempt 1 and a job that started 4 seconds after the run was created means GitHub created the event late and the runner picked it up immediately.

Your diagnostic cron (2-57/5 2-4 2 10 *) only has slots on October 2, from 02:02 through 04:57 UTC. There is no 09:59 slot. GitHub queued one of the morning slots and created the workflow hours later.

GitHub's schedule docs say this event can be delayed when Actions is busy, and that a busy queue can drop runs. There is no setting that makes the clock exact. The Shanghai reminder created at 16:25 UTC is the same kind of delay: that is 00:25 on October 3 in Asia/Shanghai, so a script that checks local time will skip it.

For a reminder that has to land inside a given hour, Actions cron will keep slipping. Use a scheduler you control.

@Rors-Box

[slyyr]

Since the workflow works with push and manual triggers, I'd investigate the scheduling event separately from the job steps.

1. Check the default branch

Scheduled workflows are associated with the repository's default branch. Confirm that the workflow file is present and active there.

2. Verify the timezone

GitHub Actions cron schedules use UTC. Compare the intended UTC execution time with the timestamps recorded for each run.

3. Distinguish event delay from runner delay

Check the run's creation and start timestamps. A workflow created hours after the expected time is a different problem from a run created on time but left waiting for an available runner.

4. Create a minimal diagnostic workflow

Use a simple scheduled job that prints the current UTC time and event information. Temporarily remove external actions, dependencies, secrets, and unnecessary conditions.

5. Collect evidence if the problem persists

Record the workflow ID, run IDs, and timestamps. If the minimal workflow is also delayed, these details can help when reporting the issue through GitHub's appropriate support channels.

GitHub documents that scheduled events can be delayed or dropped during periods of high load. Therefore, a delayed run alone doesn't establish that the repository has an account restriction or that the workflow configuration is incorrect.

If this answer helped solve your issue, please consider marking it as the accepted answer so others facing the same problem can easily find the solution too. Thanks!