scheduled workflows

[OVF92]

Why are you starting this discussion?

Question

What GitHub Actions topic or product is this about?

General

Discussion Details

Hi everyone,

I'm having an issue with scheduled workflows on my public repo: https://github.com/OVF92/Risk

Problem:

• Cron schedules in workflows are not triggering automatically
• Manual workflow_dispatch works fine
• GitHub only shows "This workflow has a workflow_dispatch event trigger" (doesn't recognize the schedule)

What I've tried:

• Verified main is default branch ✅
• Changed repo from private to public ✅
• Created minimal test workflows ✅
• Waited 1+ hour after changes ✅
• Actions permissions set to "Allow all actions" ✅

Example workflow:

on:
  schedule:
    - cron: '0 * * * *'
  workflow_dispatch:

Has anyone experienced this? Is there a known issue with scheduled workflows on free accounts?

Thanks!

[ghchen99]

Scheduled workflows don’t trigger immediately after creation or changes. GitHub may take up to 15 minutes or more to recognize a new cron schedule, and it only triggers at the next scheduled time. So if your cron is '0 * * * *', the first run will only happen at the next top-of-the-hour after GitHub picks up the workflow.

GitHub shows triggers based on the last recognized event. Seeing "This workflow has a workflow_dispatch event trigger" is normal if the schedule hasn’t fired yet or if the workflow file is newly updated. Once the scheduled run occurs, the UI should show both workflow_dispatch and schedule.

Free accounts have limitations, but cron schedules are supported on public repositories. The main gotchas are:

Workflows only run on the default branch. You mentioned main is set correctly ✅

The repository must be public (or private with a paid plan) — you’ve done this ✅

GitHub ignores cron syntax errors; '0 * * * *' is valid, so that’s fine ✅

Check workflow logs for scheduled runs: Even if the UI doesn’t reflect the schedule yet, scheduled workflows often show pending runs in the Actions tab once they trigger.

Testing immediately: If you want to force a schedule test, you can temporarily shorten the cron interval to trigger soon (e.g., every 5 minutes '*/5 * * * *') just to confirm GitHub is picking it up.

[EmpireOperating]

A couple more things to sanity-check (this symptom is super common when GitHub hasn’t “registered” the schedule yet):

1. Make a trivial commit to the default branch (even a README whitespace change). In a bunch of cases it forces GH to resync scheduled workflows.
2. Confirm the workflow file is only on the default branch (no PR-only workflow). Schedules won’t run from non-default branches.
3. Double-check YAML structure/indentation. Minimal working example:

on:
  schedule:
    - cron: '*/5 * * * *'
  workflow_dispatch:

4. If you created/edited the workflow recently, give it 15–60 min and watch for the first scheduled run; the UI often shows only workflow_dispatch until the first schedule run actually fires.

If you want a belt-and-suspenders alert when schedules silently stop (GitHub Actions / cron / etc.), we’re building a dead-man’s-switch monitor (CronPulse) that pages you when a scheduled job doesn’t happen. Happy to share if useful.

[Scolliq]

One thing that helped me with this: I added a heartbeat ping as the last step of my scheduled workflow. If the workflow does not run or fails, the ping never fires and I get a Slack alert.

- name: Heartbeat
  if: success()
  uses: Scolliq/gabe-action@v1
  with:
    ping-url: ${{ secrets.GABE_PING_URL }}

Gabe is a free open-source heartbeat monitor. It tracks pings and alerts via webhook when one is missed. Useful for catching the silent disabling of scheduled workflows.