Scheduled workflows create no runs across repositories while push and manual dispatch succeed

[GladosAI]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Schedule & Cron Jobs

Discussion Details

I am looking for help diagnosing scheduled workflows that do not create any visible runs. The same workflows run successfully through push and workflow_dispatch.

Repository names, URLs, IDs, commit hashes, exact activity timestamps, and application details have been omitted for privacy. The example below contains no credentials or private identifiers.

Observed behavior

• Existing daily schedules missed expected execution windows. There were no corresponding schedule runs in the Actions UI or the REST API, rather than queued, failed, or skipped jobs.
• I then tested a minimal workflow in the original private repository and a separate, newly created empty repository under the same account.
• The controlled observation lasted approximately one hour. The empty repository was initially private, temporarily public, and then private again. The original repository stayed private throughout.
• While the empty repository was public, I created an additional new workflow using the offset expression 2-57/5 * * * *. It was observed for approximately 38 minutes, including approximately 22 minutes while public.
• All three test workflows had zero visible schedule runs during their respective observation windows. Each workflow had successful push and manual runs: six successful control runs in total.
• An unrelated public repository had successful native scheduled runs during the same period, so the REST API's event=schedule filter was also verified against a positive control.

Minimal example

This is an equivalent reduced example; the workflow name and filename are generic placeholders.

name: Schedule test

on:
  schedule:
    - cron: '*/5 * * * *'
  workflow_dispatch:
  push:
    paths:
      - '.github/workflows/schedule-test.yml'

permissions: {}

jobs:
  clock:
    runs-on: ubuntu-24.04
    timeout-minutes: 2
    steps:
      - name: Print UTC time and trigger
        env:
          EVENT_NAME: ${{ github.event_name }}
          SCHEDULE: ${{ github.event.schedule }}
        run: |
          python3 - <<'PY'
          import datetime
          import json
          import os
          print(json.dumps({
              "utc": datetime.datetime.now(datetime.timezone.utc).isoformat(),
              "event": os.environ["EVENT_NAME"],
              "cron": os.environ.get("SCHEDULE", "")
          }))
          PY

Checks already performed

• Workflow files were committed on the default branch (main), present under .github/workflows/, and passed actionlint.
• UTC conversion and server time were checked. Both cron expressions use a five-minute interval; the offset expression also avoids the top of the hour.
• Repositories were not forks or archived during testing, workflows were active, and repository-level Actions were enabled with all actions allowed.
• The probe uses a GitHub-hosted runner and has no checkout, third-party actions, dependencies, secrets, external requests, job conditions, or environment approval requirements.
• Disabling and re-enabling the workflow, and separately repository-level Actions, did not produce a scheduled run within the subsequent observation windows.
• The temporary probes were removed after testing.

I understand that scheduled events can be delayed or dropped under high load. A finite observation window does not prove a permanent scheduler failure, and I am not assuming a confirmed platform bug.

Questions

1. Is there a supported way to check whether a cron schedule was registered or whether its event was delivered, when no workflow run exists yet?
2. Are there documented account or repository restrictions that allow push and workflow_dispatch but prevent schedule from creating runs?
3. What additional non-sensitive checks would help distinguish delayed/dropped scheduling from a registration problem? If backend investigation is needed, is there a private escalation route for sharing repository identifiers with GitHub staff?

Thank you for any guidance.

[vk26kumar]

Really thorough write-up! Since you've already ruled out the usual stuff, my guess is this is something on the account side, not the workflow itself.

As far as I know, there's no public way to check whether a cron schedule actually got registered. The API only shows runs that were created, so you can't see the difference between "never registered" and "dropped."

One thing worth knowing: scheduled runs are tied to whoever last edited the cron line. Push and manual runs work because you trigger them directly, but schedule runs happen in the background. So if something's off with the account (billing hold, some kind of flag), it could block only the scheduled runs. The fact that it failed in a brand new repo too makes me lean that way.

A few things I'd try:

• Leave one test running for a full 24 hours. New schedules sometimes take a while to kick in, and an hour might just be too short.
• Ask a friend or collaborator to make the commit that edits the cron line, and see if it starts firing then.
• Take a look at Settings → Billing in case there's a notice or failed payment.

If none of that works, I'd open a ticket at https://support.github.com. You can share the repo details privately there, and staff can see the scheduler logs.

Hope this helps!

[Himanshu-5680]

Hi @lklolzcoki,
incredible job on the debugging steps so far! Since you have already isolated the workflow and verified all standard checks, this behavior strongly points toward a silent account-level restriction or GitHub's backend scheduler aggressively dropping the jobs.
To answer your specific questions directly:

• Checking Registration: Unfortunately, there is no public UI or API to see the internal cron registration queue. However, if you hit the GET /repos/{owner}/{repo}/actions/workflows/{workflow_id}/runs API endpoint and don't even see the runs marked as queued or skipped, it confirms the scheduler is completely ignoring the trigger, rather than delaying it.

• Account Restrictions: Yes, this is a known quirk. If GitHub's automated spam filters flag the account of the person who made the last commit to that workflow file (often happens due to strict anti-crypto-mining policies), push and workflow_dispatch will still work normally, but schedule triggers get completely muted in the background.
  What you can do right now:

• Ask a collaborator (with a clean, older account history) to make a dummy commit to that workflow file. This forces the scheduler to register the job under their account instead of yours.

• Do not wait endlessly. Go straight to support.github.com, open a ticket under "Actions", and share your private repo link. They have backend visibility to immediately tell you if your cron jobs are being rate-limited or dropped at the platform level.

[GladosAI]

Update: resolved for me — schedule events are triggering after all.

After extending the observation window, scheduled runs appeared. A dedicated single-time test was created about 6 hours 19 minutes after its configured time and completed successfully. Other daily runs were about 5 hours 47 minutes to 6 hours 5 minutes late, so the delay was substantial but not a fixed six hours.

My earlier observation of no run records during a short test window was premature; it did not establish that events were being permanently ignored or that my account was restricted. The backend reason for these delays remains unconfirmed.

Thanks for the suggestions, especially the longer observation period!