Active scheduled workflow creates no schedule runs; workflow_dispatch succeeds

[brigidovinicius]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Schedule & Cron Jobs

Discussion Details

We need help diagnosing missing GitHub Actions schedule events for a public repository. We understand scheduled events are best effort and may be delayed or dropped. The API does not expose why these events have not produced runs, so we are not asserting a specific internal cause.

Repository and workflow

• Repository: https://github.com/brigidovinicius/apogee
• Default branch: main; not a fork; not archived; Actions enabled.
• Workflow: Google Calendar external monitor
• Workflow ID: 403726654
• Path: .github/workflows/google-calendar-monitor.yml
• Workflow page: https://github.com/brigidovinicius/apogee/actions/workflows/google-calendar-monitor.yml
• Workflow state: active; the job's operation variable is enabled.
• Current cron: 3,8,13,18,23,28,33,38,43,48,53,58 * * * * (UTC).
• The account modifying the cron is brigidovinicius, the repository owner.

Observed behavior

As of 2026-11-01 21:18:20 UTC, the workflow history contains six manual runs and zero runs with event schedule. This is absence of a workflow run, rather than a failed or skipped scheduled job.

The original workflow was published earlier on 2026-11-01 with cron 3-58/5 * * * *. We confirmed the default branch, repository/workflow state and actor, then disabled and immediately re-enabled the workflow at approximately 19:34:45 UTC. No automatic run appeared during the subsequent eleven-minute observation window.

We then changed the cron to the explicit list above, preserving the same twelve minutes per hour. The change was committed by the repository owner and merged to main at 19:55:54 UTC:

• PR: fix(ci): renovar agendamento do monitor Google Agenda brigidovinicius/apogee#112
• Commit: 9f05dae9895e582e1d50bf0ccf525f77924cab39
• Merge: fa5f32213334e68b08630515a1c202aae7ff6b31
• All six CI jobs passed: https://github.com/brigidovinicius/apogee/actions/runs/41343271855

A post-merge manual dispatch completed successfully from the published revision:

• Run: https://github.com/brigidovinicius/apogee/actions/runs/41344790373
• Started: 2026-11-01 20:02:43 UTC; completed: 20:02:56 UTC.
• Previous alert state restored successfully; health check succeeded; updated state artifact saved; no active incident or pending deliveries.

The published workflow and its two monitor scripts were rechecked at 21:19:52 UTC and match the reviewed commit. The monitored application was healthy when checked separately at 21:20:27 UTC. The GitHub status page reported Actions operational and no active incident when consulted; we understand this does not exclude a repository-specific or unreported problem.

Read-only diagnostic request

GET /repos/brigidovinicius/apogee/actions/workflows/google-calendar-monitor.yml/runs?event=schedule&branch=main&per_page=100

The response contains an empty workflow_runs array. We have not deleted runs or intentionally disabled scheduled execution.

Could GitHub check whether the schedule is registered and whether events were queued, delayed or dropped for this repository/workflow? Is there a supported additional diagnostic or recovery step beyond the checks and re-registration already performed?

This report contains public repository/workflow metadata only. No credentials, environment contents, private member data or alert recipients are included.

[rjsgud49]

The schedule is registered now. A schedule run showed up at 23:22:52 UTC, which lines up with the :23 slot in your cron. It ran on the merge commit fa5f322: https://github.com/brigidovinicius/apogee/actions/runs/41361827775

You can see it here:

GET /repos/brigidovinicius/apogee/actions/runs?event=schedule

So the file, branch and actor are fine. The first scheduled run just came about 3.5 hours after your last cron change (19:55 UTC). As of 00:06 UTC that's still the only scheduled run, so the 5-minute slots after it were skipped too. That's the documented best-effort behaviour (events that trigger workflows → schedule):

The schedule event can be delayed during periods of high loads of GitHub Actions workflow runs. High load times include the start of every hour. If the load is sufficiently high enough, some queued jobs may be dropped.

Moving off :00 (which you already did) is about all you can do on the GitHub side. GitHub doesn't guarantee a 12-per-hour cadence, so I don't think support will "fix" this either.

If the monitor really has to run every 5 minutes, the usual workaround is to trigger it from outside, since your workflow_dispatch path already works:

curl -X POST \
  -H "Authorization: Bearer $TOKEN" \
  -H "Accept: application/vnd.github+json" \
  https://api.github.com/repos/brigidovinicius/apogee/actions/workflows/google-calendar-monitor.yml/dispatches \
  -d '{"ref":"main"}'

Call this from any external cron (Cloudflare Workers cron trigger, cron-job.org, a small VPS, etc.) with a fine-grained token limited to this repo with "Actions: write". Docs: https://docs.github.com/en/rest/actions/workflows#create-a-workflow-dispatch-event

Your job's if: checks github.ref == 'refs/heads/main', and the state lookup already accepts workflow_dispatch runs, so both of those keep working with dispatched runs. You can keep the schedule: trigger as a fallback. With your concurrency group, an overlapping run just waits, or replaces the pending one.

[Juan-Severiano]

Hey! I checked your workflow and the cron looks fine.

Since manual runs work and a scheduled run eventually happened, I don't think the issue is in your workflow.

GitHub Actions schedules aren't guaranteed to run at exact times. They can be delayed or even skipped depending on GitHub's load.

If you really need it to run every 5 minutes, I'd suggest using an external scheduler to trigger the workflow through workflow_dispatch.

You could also check the Actions API to compare the expected runs with the actual ones.

Hope this helps!