GitHub Actions schedule event not triggering while push and workflow_dispatch work

[GurunathBhandarkavathe]

Discussion Details

Repository: https://github.com/GurunathBhandarkavathe/NewsAgent
Default branch: main
Repository type: public, not forked, not archived

Problem:
GitHub Actions schedule events are not creating workflow runs. The same workflow runs successfully with push and workflow_dispatch.

Workflows:

1. .github/workflows/publish-instagram.yml
2. .github/workflows/cron-heartbeat.yml

Evidence:

• push trigger works:
  • Publish Instagram Posts ran on push at 2026-07-30T12:01:14Z, commit d0ae379
• workflow_dispatch works:
  • Manual runs completed successfully earlier
• schedule trigger does not enqueue any run
• Cron Heartbeat has zero schedule runs
• Workflow state from API: active
• Workflow files are on default branch main
• Latest cron-changing commits are authored by GurunathBhandarkavathe and map to that GitHub account

Cron expressions tested:

• */10 * * * *
• 7,17,27,37,47,57 * * * *
• 3 * * * *
• 7 * * * *

Observed cron misses:

• Cron Heartbeat at 2026-07-30T12:03Z did not create a schedule run
• Publish Instagram Posts at 2026-07-30T12:07Z did not create a schedule run

Expected:
A workflow run with event type schedule should be created.

Actual:
Only push and workflow_dispatch runs appear. No schedule runs are created.

Relevant docs:
https://docs.github.com/actions/using-workflows/events-that-trigger-workflows

[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. ⭐

[MandeepDalavi]

From what you've described, this doesn't sound like an ARC (Actions Runner Controller) issue. schedule events are handled by GitHub itself before any runner is involved. If no workflow run is being created, the runner (or ARC) never gets a chance to execute it.

A few things I'd check:

• Verify the workflow files containing the schedule trigger are present on the repository's default branch (main).
• Confirm that Actions are enabled for the repository and there aren't any organization or enterprise policies affecting scheduled workflows.
• Make sure the repository hasn't been automatically disabled due to inactivity (scheduled workflows are disabled after extended inactivity for public repositories).
• Allow some tolerance in timing. GitHub states that scheduled workflows are not guaranteed to run at the exact minute and can be delayed or, under heavy load, occasionally skipped.
• Check whether any recent repository ownership or default branch changes occurred after the workflow was created.

Since both workflows with different cron expressions fail to generate any schedule events, while push and workflow_dispatch work correctly, the problem appears to be with the scheduling service rather than the workflow definitions themselves.

If you've already verified all of the above, I'd recommend opening a GitHub Support ticket. The absence of any schedule event in the Actions history suggests the scheduler is never enqueueing the workflow, which is something only GitHub can investigate.

[GurunathBhandarkavathe]

Hey Mandeep, Thanks for the suggestions. I have already verified all the suggested one, not sure why it's not working, let me know if we can discuss offline. Thanks Guru Bhandarkavathe

…

On Thu, Jul 30, 2026 at 6:05 PM Mandeep Dalavi ***@***.***> wrote: A helpful GitHub Community reply could be: From what you've described, this doesn't sound like an ARC (Actions Runner Controller) issue. schedule events are handled by GitHub itself before any runner is involved. If no workflow run is being created, the runner (or ARC) never gets a chance to execute it. A few things I'd check: - Verify the workflow files containing the schedule trigger are present on the repository's *default branch* (main). - Confirm that *Actions are enabled* for the repository and there aren't any organization or enterprise policies affecting scheduled workflows. - Make sure the repository hasn't been automatically disabled due to inactivity (scheduled workflows are disabled after extended inactivity for public repositories). - Allow some tolerance in timing. GitHub states that scheduled workflows are not guaranteed to run at the exact minute and can be delayed or, under heavy load, occasionally skipped. - Check whether any recent repository ownership or default branch changes occurred after the workflow was created. Since *both* workflows with different cron expressions fail to generate *any* schedule events, while push and workflow_dispatch work correctly, the problem appears to be with the scheduling service rather than the workflow definitions themselves. If you've already verified all of the above, I'd recommend opening a GitHub Support ticket. The absence of any schedule event in the Actions history suggests the scheduler is never enqueueing the workflow, which is something only GitHub can investigate. — Reply to this email directly, view it on GitHub <#203473?email_source=notifications&email_token=AU6ILDLNT5FSHSUHRYOJCJT5HM6ITA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZYGQYDCOJZUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-17840199>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AU6ILDP7HWRGSDITUKMKKBL5HM6ITAVCNFSNUABIKJSXA33TNF2G64TZHMZTAMJVG4ZTGNBUHNCGS43DOVZXG2LPNY5TCMBVGI2DENRTUF3AE> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AU6ILDI25DCLPOUL7THVMA35HM6ITA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZYGQYDCOJZUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVJTG633UMVZF62LPOM> and Android <https://github.com/notifications/mobile/android/AU6ILDPOBKTHXQM2T6HHJG35HM6ITA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZYGQYDCOJZUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVZTG633UMVZF6YLOMRZG62LE>. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***>

[alexliluz]

I checked the repository's current public API state rather than only the YAML.
As of 2026-07-30T15:19:47Z:

• main is still the default branch;
• both publish-instagram.yml and cron-heartbeat.yml report state: active;
• both files on main contain schedule: - cron: "*/5 * * * *";
• the latest schedule-changing commit, de2f317, was committed by
  GurunathBhandarkavathe at 2026-07-30T14:03:33Z;
• GET /repos/GurunathBhandarkavathe/NewsAgent/actions/runs?event=schedule
  still returns total_count: 0;
• push runs after the same commit are created successfully.

So this is not a job, runner, environment, secret, permission, or concurrency
failure. Those are evaluated only after a workflow run exists. GitHub is
recognizing both workflow files, but the scheduler has not created a
schedule event.

First, restore the real publishing workflow to its intended production
schedule. Leaving publish-instagram.yml at every five minutes could publish
up to twelve stories per hour if the scheduler starts working suddenly. Keep
only the side-effect-free Cron Heartbeat on a diagnostic cadence.

Then use the heartbeat for one controlled workflow-state probe:

gh workflow disable cron-heartbeat.yml \
  --repo GurunathBhandarkavathe/NewsAgent

gh workflow enable cron-heartbeat.yml \
  --repo GurunathBhandarkavathe/NewsAgent

gh api \
  repos/GurunathBhandarkavathe/NewsAgent/actions/workflows/cron-heartbeat.yml \
  --jq '{id, name, path, state, updated_at}'

Disable/enable is an officially supported operation. It is not documented as
a guaranteed scheduler repair, so treat it as a registration/actor probe, not
as the root-cause claim. After enabling, wait for at least two non-top-of-hour
windows and check:

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

GitHub documents that schedules can be delayed or dropped under load,
especially at the start of an hour, but */5 is a supported expression and
the complete absence of events across more than a dozen windows is stronger
than a single delayed run. You also already tested offset minutes, so changing
cron expressions repeatedly is no longer a useful discriminator.

If the heartbeat remains at zero after re-enable and two further windows,
attach these exact API facts to GitHub Support:

• repository and default branch;
• workflow IDs 323614781 and 323669785;
• active workflow-state responses;
• commit de2f317 and its UTC timestamp;
• the zero-result event=schedule response;
• successful push run 30549858020;
• the first and last missed UTC windows after the re-enable.

That gives Support a scheduler-registration case with a control workflow,
rather than a generic "cron was late" report.

Official references:

• Events that trigger workflows: schedule
• Troubleshooting workflow triggers
• Disabling and enabling a workflow