Vivere / Answers

Scheduled workflow disabled after 60 days of inactivity: how to keep it running

GitHub switches off scheduled workflows in a public repository after 60 days without activity. Turning one back on takes a click; here is what each way of keeping it on costs.

The banner in the Actions tab says the scheduled workflow was disabled because there has been no activity in the repository for 60 days. Turning it back on takes one click. Keeping it on is the real question, and each way of doing that has a cost worth knowing before you pick one.

The rule

GitHub's documentation says, as of October 2026, that in a public repository scheduled workflows are automatically disabled when no repository activity has occurred in 60 days. Three details follow from the wording:

• It is about public repositories. The documentation does not apply it to private ones.
• It disables scheduled workflows. Nothing is deleted, but a disabled workflow does not run for any trigger until it is enabled again.
• The documentation does not define activity. A push to the repository is activity on any reading. Whether opening an issue, a star or a scheduled run counts is not stated, so do not build on it.

Forks are covered by a separate rule: when a public repository is forked, scheduled workflows in the fork start disabled.

Confirm that this is what happened

The Actions tab shows the banner on the workflow. From the command line, the workflow's state says it directly:

gh workflow list --all --json name,state

disabled_inactivity is this rule. disabled_manually means a person or a script disabled it, and disabled_fork means the repository is a fork. If the state is active and the schedule still does not run, the cause is something else; GitHub Actions scheduled workflow stopped running goes through the others.

Turn it back on

Any of these works, from GitHub's page on disabling and enabling workflows and the events documentation:

• In the Actions tab, select the workflow and press Enable workflow.
• gh workflow enable nightly.yml
• The REST API: PUT /repos/OWNER/REPO/actions/workflows/nightly.yml/enable, which sets the state to active.
• A commit that changes the workflow's cron line, made by someone with write access. GitHub reactivates the workflow and makes that person its actor.

The runs that were due while it was disabled do not happen later. If the job works through a period, such as a daily export, the missing days need catching up by hand; catching up a missed scheduled run covers doing that without processing the wrong dates.

Notifications for a re-enabled scheduled workflow go to the user who re-enabled it, according to GitHub's notification rules. Whoever presses the button becomes the person who hears about its failures.

Keep it from happening again

Give the repository real activity

If the repository is maintained, the problem solves itself: commits arrive more often than every 60 days. The repositories that hit the rule are the ones whose only purpose is the schedule, such as a data scraper, a status checker or a backup job, and for those a regular commit is the thing that does not happen.

Make the repository private

The documented rule is for public repositories. A private repository is billed for GitHub-hosted runner minutes beyond the account's included quota, and GitHub's billing page says that without a valid payment method usage is blocked once the quota is used up. A short nightly job uses a small part of the included minutes, but the quota is now something to watch.

Trigger it from outside instead of on a schedule

Replace the schedule trigger with workflow_dispatch and start the workflow from a scheduler you already run, through the workflow dispatch API or gh workflow run nightly.yml. The documented rule is about scheduled workflows, and a workflow with no schedule trigger is not one. The cost is a second system with a token that can run your workflows, and that system can stop too. Scheduled workflow runs late or is skipped has the API call.

Keepalive actions, and why to be careful

A number of community actions exist to stop the disabling, either by pushing an empty commit before day 60 or by calling the enable API on a schedule. Two things are worth knowing before adding one. The best-known of them, gautamkrishnar/keepalive-workflow, is no longer available: as of October 2026 GitHub's API answers requests for that repository with "Repository access blocked", giving terms of service as the reason, since April 2025. And GitHub's terms for Actions say that on GitHub-hosted runners, Actions should not be used for activity unrelated to the production, testing, deployment or publication of the repository's software project. Read them against your own case before relying on a workaround GitHub has acted against once.

Accept the rule, and get told when it fires

For a repository that will never see regular commits, the least fragile option is to let GitHub apply its rule and make sure you hear about it the day it does, then re-enable the workflow. That needs a check that does not live inside the repository, because a watchdog workflow in the same public repository is disabled by the same rule on the same day. Getting an alert when a scheduled workflow does not run compares the ways to do it.

With Vivere it is a heartbeat monitor with the workflow's cron expression, and the Vivere ping action at the end of the job:

      - uses: nicholasbergesen/vivere-ping-action@v1
        if: always()
        with:
          url: ${{ secrets.VIVERE_PING_URL }}
          status: ${{ job.status }}

The first scheduled run that does not happen, for this reason or any other, is an alert by email, webhook, Slack, Discord, Telegram or ntfy once the grace runs out. The free plan covers 25 monitors with email and webhook alerts.

Common questions

Last reviewed October 2026.

Related

• GitHub Actions scheduled workflow stopped running: how to find out why — A GitHub Actions cron workflow stopped firing and nothing told you. The 60-day inactivity rule, the default branch, forks, delays and dropped runs at the top of the hour, edits that drop the schedule, billing, and how to notice the next time.
• How to get an alert when a GitHub Actions scheduled workflow doesn't run — GitHub's notifications cover runs that happen. Three ways to be told when a scheduled workflow does not run: a watchdog workflow in the same repository and where it falls short, polling the API from elsewhere, and a dead man's switch, with a grace period sized from your own run history.
• GitHub Actions cron not triggering on a branch or a fork — A GitHub Actions schedule that never fires: the default-branch rule, edits to the cron line on a branch, a changed default branch, forks with scheduled workflows disabled, testing with workflow_dispatch and gh workflow run, and the cron syntax GitHub accepts.