GitHub Actions scheduled workflow stopped running

Scheduled workflows are disabled automatically after 60 days without repository activity. That is the first thing to check, and there are four more.

A workflow with a schedule trigger that used to run every night and now does not is usually not broken. GitHub turns scheduled workflows off on purpose, and the notice is easy to miss.

1. The 60-day inactivity rule

In a public repository, GitHub disables scheduled workflows after 60 days of repository inactivity. Commits, issues and pull requests count as activity; scheduled runs themselves do not. A repository that exists only to run a nightly job therefore switches itself off roughly every two months.

Check the Actions tab: a disabled workflow shows a banner saying scheduling is disabled, with a button to re-enable it. GitHub emails the repository owner when this happens, which is worth a filter rather than a rule that deletes it.

The durable fix is to make the repository genuinely active, or to accept the limit and monitor for the silence rather than relying on remembering.

2. The schedule only runs on the default branch

The schedule event fires only for the workflow file as it exists on the repository's default branch. A cron trigger added on a feature branch is never scheduled, however correct the YAML is. This catches people twice: once when developing a new scheduled workflow, and again after renaming the default branch from master to main.

3. Runs are queued, not guaranteed

Scheduled workflows are best-effort. During periods of high load, runs can be delayed by minutes or dropped entirely, and the effect is worst at the top of the hour because that is where everybody schedules. Moving 0 * * * * to 17 * * * * is a real, measurable improvement.

Cron in GitHub Actions is always interpreted in UTC. There is no timezone setting, so a job that must run at a local hour has to be scheduled against UTC and adjusted twice a year, or scheduled twice and guarded inside the job.

4. The workflow, the repository, or billing is disabled

Several states stop scheduling without breaking anything visibly:

Someone disabled the workflow manually in the Actions tab.
The repository was archived, which disables Actions entirely.
For private repositories, the account's included Actions minutes ran out or a spending limit was reached. Jobs then fail to start rather than running and failing.
Actions was disabled at the organisation level, or the workflow's permissions were restricted by a policy change.

5. It ran, and did nothing useful

If the run appears in the Actions tab but the work did not happen, check whether a step was skipped by an if: condition that depends on the event name. A step conditioned on github.event_name == 'push' is skipped on a scheduled run, and the job still reports success.

Getting told when it stops

Every cause above is silent from the repository's point of view: there is no failed run to notify you about, because there is no run at all. GitHub's own failure notifications cannot help, since they fire on failures.

Add a final step that reports success to something outside GitHub:

jobs:
  nightly:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: ./scripts/nightly.sh
      - name: Report success
        run: curl -fsS -m 10 --retry 3 -o /dev/null https://vivere.dev/p/${{ secrets.VIVERE_MONITOR }}

Set the monitor's period to the schedule and its grace to the delay you can tolerate. If the workflow is disabled after 60 days, if the run is dropped at a busy hour, or if the job fails before the last step, the ping does not arrive and you are alerted — by email, Slack, Discord, Telegram or a webhook.

Add if: failure() to a second step pinging /fail and you also get told immediately when a run breaks, rather than waiting for the deadline.

Common questions

Why did my GitHub Actions scheduled workflow stop?

GitHub disables scheduled workflows in a public repository after 60 days with no commits or other activity. The workflow is not deleted; it simply stops being triggered until someone pushes a commit or re-enables it in the Actions tab. Repositories that only receive scheduled runs hit this reliably.

Why does my cron schedule run late in GitHub Actions?

Scheduled workflows are queued, not guaranteed. Runs at popular times, especially on the hour, can be delayed by several minutes or dropped entirely when the platform is busy. Scheduling at an odd minute rather than :00 measurably reduces it.

Does a schedule work on a branch other than the default?

No. The schedule event only runs on the default branch. A workflow file with a cron trigger on a feature branch is never scheduled, which is a common surprise after a rename of the default branch.

Find out without looking

Vivere watches for the ping that does not arrive. Add one line to the job, pick where alerts should land, and you hear about the run that never happened.

Start free Read the quickstart

Ten monitors, a status page, email and webhook alerts. No card.

Last reviewed September 2026.

Cron job not running: how to find out why — A cron job stopped running and nothing told you. The five usual causes in the order worth checking, how to read the logs, and how to find out next time without looking.
A dead man's switch for your scripts — What a dead man's switch is, why it catches failures that error-based alerting cannot, how to build one with cron and curl, and the timing rules that stop it crying wolf.
Kubernetes CronJob missed its schedule — A Kubernetes CronJob did not create a Job. startingDeadlineSeconds, the 100-missed-schedules rule, concurrencyPolicy, suspended CronJobs, and how to alert on the run rather than the pod.