Scheduled workflow does not create any runs although the workflow is active on main

[dealvia360]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Schedule & Cron Jobs

Discussion Details

Hello,

I am experiencing an issue with a scheduled GitHub Actions workflow in a private repository.

The workflow is active and exists on the default branch main, but GitHub is not creating any workflow run objects for the configured schedule events.

Workflow details:

• Workflow path: .github/workflows/staging-cron.yml
• Default branch: main
• Workflow state: active
• Monitoring schedule: 2/5 * * * *
• Stories schedule: 5/10 * * * *

Expected behavior:

GitHub should create a workflow run with event=schedule for every matching cron slot.

Actual behavior:

No workflow run object is created.

There are no runs in any of these states:

• queued
• waiting
• in_progress
• skipped
• cancelled
• completed

Checks already completed:

• The workflow file exists on the default branch.
• GitHub Actions is enabled.
• The workflow is active.
• Both cron expressions are valid.
• The minimum five-minute interval is respected.
• There are no incompatible branch or path filters.
• Repository Actions policies allow the workflow.
• The workflow actor is active.
• The Actions quota is not exhausted.
• YAML validation and actionlint pass.
• Repository CI workflows triggered by push and pull request work normally.
• The GitHub Environment used by the workflow has no required reviewers or wait timers.

The workflow previously created real scheduled runs successfully, but newer schedule events are no longer materialized.

The application-level safety gate cannot explain the problem because it is evaluated only after GitHub creates a workflow run. In this case, GitHub does not create the run object at all.

The issue continued after the recent GitHub Actions incidents were reported as resolved.

Could GitHub staff confirm whether this may be an internal scheduler registration or event dispatch issue?

Is there a safe supported way to refresh the schedule registration for this workflow without changing its functional behavior?

I can provide repository ID, workflow ID, previous scheduled run IDs, missed UTC slots, and the redacted workflow file if GitHub staff needs them.

No secret, credential, OIDC token, or environment-variable value is included in this discussion.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[initial-d]

Because no run object is created at all, I agree this should be debugged as a scheduler/trigger materialization problem, not as a runner, environment, secret, or application failure.

A supported, low-risk refresh path is to disable and re-enable only this workflow, then observe a few non-top-of-hour windows:

gh workflow disable staging-cron.yml --repo OWNER/REPO
gh workflow enable staging-cron.yml --repo OWNER/REPO

gh api repos/OWNER/REPO/actions/workflows/staging-cron.yml \
  --jq '{id, name, path, state, created_at, updated_at}'

Then check whether GitHub has created any scheduled run objects:

gh api 'repos/OWNER/REPO/actions/runs?event=schedule&per_page=20' \
  --jq '{total_count, runs: [.workflow_runs[] | {
    id, name, event, status, conclusion, created_at, run_started_at, html_url
  }]}'

GitHub documents disable/enable as a supported workflow operation:
https://docs.github.com/en/actions/managing-workflow-runs-and-deployments/managing-workflow-runs/disabling-and-enabling-a-workflow

And the schedule docs note that scheduled workflows can be delayed or dropped under high load, especially at the start of the hour:
https://docs.github.com/actions/using-workflows/events-that-trigger-workflows#schedule

Your case is stronger than an ordinary delayed cron, though, because you are seeing zero run objects across valid cron windows while push/PR workflows work. If disable/enable does not produce schedule runs after several windows, I would send Support/GitHub staff a compact evidence packet:

Repository id/name:
Workflow id:
Workflow path: .github/workflows/staging-cron.yml
Default branch: main
Workflow state after re-enable:
Last known successful schedule run id/time:
First missed UTC slot:
Most recent missed UTC slot:
Response from actions/runs?event=schedule:
Confirmation that push/PR/manual runs still create run objects:

One small YAML note: 2/5 * * * * and 5/10 * * * * are valid step expressions, but for debugging I would temporarily keep one side-effect-free heartbeat workflow on an offset minute such as 17,32,47 * * * *. That avoids the top-of-hour load window and avoids repeatedly changing the production workflow while you are trying to prove whether the scheduler is registering events.

If the heartbeat also stays at zero, that is the cleanest evidence that the missing piece is before job execution: the scheduled event is not being materialized for the workflow/repository.

[dealvia360]

Thank you for the suggestion. I completed both diagnostic steps.

1. Disable and re-enable test

I disabled and immediately re-enabled only the affected workflow:

• Repository: dealvia360/dealvia360
• Workflow: .github/workflows/staging-cron.yml
• Workflow ID: 342988302

The workflow correctly transitioned:

active → disabled_manually → active

The workflow file, schedules, secrets, environments, and repository configuration were not modified.

After re-enabling it, I observed more than 52 minutes and crossed:

• 10 valid Monitoring schedule slots
• 5 valid Stories schedule slots

GitHub created zero new schedule workflow run objects. There were no queued, waiting, skipped, cancelled, or completed runs.

2. Independent heartbeat workflow

I then created a completely independent and side-effect-free diagnostic workflow:

• Workflow name: Scheduler Heartbeat Diagnostic
• Workflow ID: 344585041
• Path: .github/workflows/scheduler-heartbeat.yml
• State: active
• Default branch: main
• Schedule: 17,32,47 * * * *

The heartbeat workflow has:

• permissions: {}
• no checkout
• no environment
• no secrets or variables
• no OIDC
• no URLs or network requests
• one job with an impossible condition, so the job would always be skipped

It was merged into main at commit:

c93583651034b9824ef614b39b07a45fb47ab220

I observed these valid UTC slots:

• 12:32
• 12:47
• 13:17
• 13:32

GitHub again created zero workflow run objects.

Push-triggered workflows in the same repository continue to be created and complete successfully.

This now appears to be a repository-level schedule event materialization problem occurring before job evaluation, rather than an issue with the original workflow, runner, environment, secrets, OIDC, or application logic.

Could GitHub staff please inspect the internal scheduler registration and event dispatch state for:

• Repository ID: 1338814600
• Workflow ID 342988302
• Workflow ID 344585041

Both workflows remain active. The application cron gate remains disabled, and no external requests have been made.