Why your GitHub Actions scheduled workflow stopped running

Your scheduled workflow ran like clockwork for weeks, then just stopped. No error, no failed run, no email. It didn't break — GitHub disabled it, on purpose, and the only place it says so is a banner you never looked at.

This is one of the most common ways a cron quietly dies, and it catches exactly the projects that rely on it most: the quiet side project that does one scheduled job and nothing else.

The 60-day rule

GitHub automatically disables schedule-triggered workflows after 60 days of no activity in the repository. "Activity" means commits, pushes, and the like — not the workflow's own scheduled runs. So a repo whose only heartbeat is the cron itself will always trip this: the cron running doesn't count as activity, so the clock keeps ticking until GitHub switches it off.

60 days

of no repo activity, then scheduled workflows auto-disable

public repos

where this auto-disable rule applies

not counted

the workflow's own scheduled runs don't reset the clock

off by default

scheduled workflows don't run on forks

The other silent zero: forks

If you forked a repo expecting its scheduled workflow to run for you, it won't. Scheduled workflows are disabled by default on forks and have to be explicitly enabled in the Actions tab. Plenty of "the cron isn't running" reports are just a fork that was never switched on.

Turning it back on — and keeping it on

Re-enabling is a click: open the workflow in the Actions tab and enable it. But it'll disable again in another 60 idle days unless the repo sees real activity. The common workaround is a second tiny scheduled workflow that makes a trivial commit on a slow cadence, resetting the clock so your real cron survives:

My GitHub Actions scheduled workflow keeps getting disabled after a couple of months because the repo has no other activity. Write me a second, tiny scheduled workflow whose only job is to keep the repo "active" so my real scheduled workflows don't get auto-disabled.

Requirements:
- Run on a schedule roughly weekly, plus workflow_dispatch.
- Make a trivial commit to a throwaway file (e.g. touch a timestamp file and commit it) using the built-in GITHUB_TOKEN, so the repo shows recent activity.
- Add a comment explaining that GitHub disables scheduled workflows after 60 days of no repository activity on public repos, and that this "keepalive" commit resets that clock.
- Keep it minimal and safe — no force pushes, no touching real files.

Give me the full workflow file.

The fix that survives GitHub turning it off

A keepalive commit patches this one cause, but it can't catch the others — a broken run, a rotated secret, a downstream API that started failing. All of them share the same symptom: the job stops and nobody's told. GitHub schedules your workflow; it doesn't judge whether the work got done.

The durable answer is a heartbeat: have the job report success on every run, and get alerted the moment a report goes missing — whether the cause was a disabled workflow, a 500, or a run that never fired.