Newly created private repository creates no schedule runs; push works

[yche441]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Schedule & Cron Jobs

Discussion Details

On November 6, 2026, a newly created private personal repository on GitHub Free
has produced no schedule run objects, although a push-only diagnostic succeeded.
All times below are UTC.

The workflow files are on the default branch main. The repository is not a fork,
archived or disabled. Actions are enabled. The owner email is verified.
The repository Actions Policies page says no policies have been created.

A minimal schedule-only probe has been on main since about 14:36 with cron
*/5 * * * *. It uses permissions: {}, ubuntu-latest, and only prints the date.
No checkout, credentials or external services are involved. A successful push
diagnostic completed at 14:35, but no schedule events appeared afterward.

We tried a single workflow disable/enable cycle, then a repository Actions
disable/enable cycle around 15:20. A second minimal schedule-only probe was
created directly through the owner's GitHub web session at 15:46:35.
Both probes are capped by workflow run_number and do not use manual dispatch.
No Run now or rerun has been used. GET actions/runs filtered by event=schedule
still returns total_count=0 at the latest check.

Is there a known delay or restriction in schedule registration for newly created
private repositories? How can we distinguish registration failure from delayed
event delivery, or request staff investigation without publishing private
repository details? We can provide identifiers privately through an appropriate
GitHub support channel if requested.

Minimal probe:
name: Schedule probe
on:
schedule:
- cron: '*/5 * * * *'
permissions: {}
jobs:
clock:
if: github.event_name == 'schedule' && github.run_attempt == '1' && github.run_number <= 3
runs-on: ubuntu-latest
timeout-minutes: 1
steps:
- run: date -u

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

[nikoladimitrov98]

Your probe looks correct. It's on the default branch, the cron is the 5-minute minimum, and the if: would still leave a (skipped) run record, so event=schedule returning 0 means no schedule event was created at all, not that the job was filtered out.

A few things to check that weren't in your list:

1. The workflow state

gh api repos/OWNER/REPO/actions/workflows --jq '.workflows[] | "\(.name)  \(.state)  \(.path)"'

The state should be active. Anything else (disabled_manually, disabled_inactivity) explains it. If the probe doesn't appear at all, GitHub didn't parse the file. Open it in the Actions tab, where YAML errors show up.

2. Who last changed the cron line

Scheduled runs are tied to the user who last modified the cron syntax in the workflow file (see the schedule docs). If the probe was committed by a bot, a GitHub App or an automation token rather than your own account, edit the cron line once from your account in the web editor (for example */5 → */10) and wait about 30 minutes.

3. Avoid the top of the hour

The same docs say scheduled events can be delayed when Actions is under heavy load, especially at the start of every hour, and some can be dropped. With */5 most slots should still fire. For a cleaner test, an odd offset like 7,22,37,52 * * * * avoids the busiest minutes.

How to tell "never registered" from "delayed"

• Delayed: runs eventually appear with event: schedule, just late or with gaps. The run's created_at shows how late it was.
• Never registered: zero schedule runs for hours, even after a fresh commit that changes the cron line, while push runs work. That's what you have now.

If it's still zero after step 2, it's on GitHub's side and needs staff to look. You don't need to share private code. The workflow ID from step 1, the repo's numeric ID (gh api repos/OWNER/REPO --jq .id) and the time you pushed the probe are enough for them to find it.

Two other threads this week report scheduled runs going missing (#212356, #212402). githubstatus.com had Actions incidents on Nov 4–5 but none that mention schedules, so I can't say it's a known incident.