Scheduled action in fork keeps getting disabled

[marionbarker]

Why are you starting this discussion?

Question

What GitHub Actions topic or product is this about?

Schedule & Cron Jobs

Discussion Details

Overview

There are a number of individuals who support their treatment of Diabetes using one or more open-source apps.

We share the code for the .github/workflows/build_xxx.yml files freely among these Diabetes open-source apps. They are not all identical but are substantially the same. The newest version, included in LoopWorkpace, dramatically minimizes the number of runners used and shifts the scheduled time to weekends when GitHub tends to be less busy.

The Problem

One of the apps (but only one) will not stay "enabled".
The app is active and has recent commits in the upstream repository.

• Scheduled build action does not run because it is "disabled"
• Must first enable the build action
• Manually run the build action (which is successful)
• GitHub automatically disables that action

Source Repositories

This is a partial list of the open-source apps that are actively in use by people who rely on scheduled updates to bring in new versions to their TestFlight app.

Open-Source App	Schedule OK?	Forks	Link
Loop	❌	7.1k	https://github.com/LoopKit/LoopWorkspace
Trio	✅	1.2k	https://github.com/nightscout/Trio
LoopFollow	✅	1.0k	https://github.com/loopandlearn/LoopFollow

Fork that is automatically disabled

This is an example of a fork from the LoopKit/LoopWorkspace repository which is automatically disabled following manual run. It is hosted in a free GitHub organization. Note that we recommended use of a free organization for people who build more than one app. This way they only need to enter the Secrets one time to build the apps.

• https://github.com/docs-test/LoopWorkspace/actions/workflows/build_loop.yml

Forks from a different source repo without the problem

Here are a few examples of forks in the same free GitHub organization for which the scheduled builds are fine.

• https://github.com/docs-test/Trio/actions/workflows/build_trio.yml
• https://github.com/docs-test/LoopFollow/actions/workflows/build_LoopFollow.yml

[Nixxx19]

Hey! @marionbarker, I saw your profile and I’m impressed with your work.

Why this happens

• GitHub disables scheduled workflows in forks by default (forks of public repos). :contentReference[oaicite:1]{index=1}
• GitHub also automatically disables scheduled workflows in public repos that have had no repository activity for 60 consecutive days. :contentReference[oaicite:2]{index=2}
• Org or repo Actions policy can prevent or re-disable workflows (Actions permissions / allowed actions). :contentReference[oaicite:3]{index=3}

What to check (quick)

1. Repo Settings → Actions → General

   • Ensure Actions are enabled for the fork and that workflows are allowed.
   • If your organization restricts Actions, the org policy may be re-applying and disabling schedules. :contentReference[oaicite:4]{index=4}

2. Workflow status in the fork

   • Open the workflow file page (Actions → the workflow) and confirm it’s enabled. If it’s enabled and later disabled, note the timestamp and who (or what) disabled it.

3. Activity window

   • Has the fork been idle >60 days? If so, scheduled jobs can be auto-disabled. Add some repository activity or keep it in sync with upstream. :contentReference[oaicite:5]{index=5}

4. Upstream vs fork behavior

   • If you don’t need the cron to run in forks, guard your jobs so schedules only run in the upstream repo:

     jobs:
       build:
         if: ${{ github.event.repository.fork == false || github.event_name != 'schedule' }}

     That prevents forks from even attempting scheduled runs (and avoids churn). :contentReference[oaicite:6]{index=6}

5. Organization-level reconfiguration

   • If the fork lives in an organization, check the org Actions policies (Owners can change). A policy may disable or limit scheduled workflows periodically. :contentReference[oaicite:7]{index=7}

Fixes / workarounds

• Enable the workflow manually in the fork and ensure the repo has some recent activity (commits, pushes) so it won’t be auto-disabled for inactivity. :contentReference[oaicite:8]{index=8}
• Move scheduled jobs to the upstream repo (preferred): keep the cron in the canonical repo so forks don’t need schedules at all.
• Add an if guard to skip schedule runs in forks (example above). This avoids the whole enable/disable dance. :contentReference[oaicite:9]{index=9}
• Check org settings and ask org owners to allow Actions for that repository if an org policy is clobbering your enable. :contentReference[oaicite:10]{index=10}
• If behavior is inexplicable, collect timestamps/screenshots and open a GitHub Support ticket; they can inspect if a platform policy or automated process is re-disabling it.

If you want, paste the fork repo URL here (or the Actions → workflow run logs / timestamps when it was disabled) and I’ll point to the precise setting most likely responsible.

Hope this helps, have a nice day!

[EmpireOperating]

One extra angle to check (since you’ve got multiple repos in the same org behaving differently):

• Fork scheduling rules: GitHub will disable schedules on forks in some cases, and it’s not always obvious which workflow/repo trips the policy. If the problematic repo is a fork, verify the fork-specific Actions settings and whether GitHub is auto-disabling due to inactivity/permissions.
• Actions permissions (Org + Repo): in the problem repo, confirm Settings → Actions → General matches the working repos (allowed actions, workflow permissions, etc.). A subtle difference (e.g. restrictive policy) can cause schedules to get disabled again.
• “Last actor” / identity edge cases: if the last editor of the workflow file lost access / was removed / suspended, schedules can stop or get weird. A trivial commit to the workflow file by an active maintainer sometimes clears it.

Given this is safety-critical-ish (people relying on TestFlight updates), it’s worth adding a guardrail: an external monitor that alerts when the scheduled build doesn’t happen (or when workflows get disabled). That way you find out immediately instead of days later.

[github-actions[bot]]

🕒 Discussion Activity Reminder 🕒

This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions:

1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as out of date at the bottom of the page.

2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own.

3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution.

Note: This dormant notification will only apply to Discussions with the Question label. To learn more, see our recent announcement.

Thank you for helping bring this Discussion to a resolution! 💬