GitHub Actions "schedule disabled after 60 days of inactivity"

By Kaveh Alemi·Latchkey

Scheduled (cron) workflows are automatically disabled after 60 days without any repository activity. The cron stops firing silently until a commit re-activates it or you re-enable the workflow. This is policy, not a runner fault.

What this error means

A previously working scheduled workflow no longer runs, and the workflow shows as disabled in the Actions tab.

This scheduled workflow was disabled automatically because the repository
had no activity for 60 days. Re-enable it to resume scheduled runs.

Diagnose it: is the job queued, or is the runner gone?

A job that never starts and a job whose runner disappeared mid-run look similar in the UI and have opposite causes. The first is a labelling or capacity problem, the second is the runner being killed, usually by memory pressure or a spot reclaim.

- name: Runner facts
  run: |
    echo "runner name: $RUNNER_NAME"
    echo "os/arch:     $RUNNER_OS/$RUNNER_ARCH"
    nproc; free -h; df -h /
    echo "labels this job asked for: ${{ toJSON(job) }}"

Common causes

60 days without repository activity

No pushes or other activity occurred, so GitHub auto-disabled the schedule to save resources.

Workflow left disabled

The workflow remains disabled until explicitly re-enabled or activity resumes.

How to fix it

Re-enable the scheduled workflow

1. Open the workflow in the Actions tab and choose Enable workflow.
2. Push a small commit to register activity if needed.
3. Confirm the cron resumes on the next scheduled tick.

gh workflow enable nightly.yml

The failures that are not your workflow

• Exit 137 is the kernel out-of-memory killer, not an application error. Check free -h above against your peak usage.
• Disk exhaustion presents as unrelated write errors deep in a build. GitHub-hosted runners ship roughly 14 GB of free space, which a Docker-heavy job can exhaust.
• A lost connection to the server on a self-hosted runner is usually the host being reclaimed or rebooted, not a network fault in your job.
• A job that starts and immediately fails with no step output normally failed during runner setup, before your workflow ran at all.

How to prevent it

• Keep the repository active, or re-enable scheduled workflows after long quiet periods.
• Monitor critical cron workflows so a silent disable is noticed quickly.

Frequently asked questions

Related guides

References

• GitHub Actions documentation
• Workflow syntax for GitHub Actions