Two-hour scheduled workflow creates events only every 3–9 hours — how to diagnose missing triggers?

[sergezd]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Schedule & Cron Jobs

Discussion Details

Our private repository has one active Actions workflow on its default branch with this UTC schedule:

on:
  schedule:
    - cron: '13 0,2,4,6,8,10,12,14,16,18,20,22 * * *'

Between October 27 and 31, 2026, thirteen schedule events were created, with intervals ranging from 3h8m to 9h30m (median 7h6m), despite the two-hour configuration. During this interval we renewed the equivalent 13 */2 * * * definition to the explicit hours above; both specify every two hours.

The latest two observed events were October 30 at 22:14:38 UTC and October 31 at 05:30:05 UTC. The latest job started three seconds after its event and passed; missed opportunities have no visible queued or failed run. Repository Actions are enabled, and the workflow is active on the default branch.

We recognize schedules can be delayed or dropped, as described in the schedule documentation. Is there a way to determine why so many opportunities are missing, or another native schedule condition we should check? We can provide private workflow/run details through an appropriate private channel.

[Sagargupta16]

No. A schedule tick that GitHub drops leaves nothing behind: no run object, so no jobs, logs or annotations, no audit-log entry, and no API that lists the ticks that were due. The list you already have, runs filtered by event=schedule, is the whole native record:

gh api "repos/OWNER/REPO/actions/runs?event=schedule&per_page=100" \
  --jq '.workflow_runs[] | [.created_at, .run_started_at, .conclusion] | @tsv'

There is no other condition to check. The two documented ones do not apply (your workflow is on the default branch, and the 60-day inactivity disable only hits public repositories), and your :13 offset already avoids the top-of-hour load the schedule docs name. githubstatus.com shows one Actions incident in your window, "delays affecting Actions workflows" from 17:50 to 19:23 UTC on 30 October (https://stspg.io/5cd2m4n59spv). That covers the 18:13 slot and nothing else; the 22:14 to 05:30 gap had no incident. Same reports since 27 October in #211380, #211641, #211637 and #211632, none with a configuration cause.

The private channel is a Support ticket, which takes technical issues on Pro, Team and Enterprise (Free accounts get this forum). Send the repository, the workflow id and the created_at list above.

Until it clears, drive the workflow from a clock you control: add workflow_dispatch: beside schedule: and have any external cron (a server, Cloud Scheduler, cron-job.org) run

gh workflow run FILE.yml --repo OWNER/REPO --ref main

or POST /repos/OWNER/REPO/actions/workflows/ID/dispatches with a fine-grained token limited to this repository and Actions: read and write. Keep schedule: as the fallback.