No notification - workflow disabled after 60 days

GitHub Actions workflows are disabled after 60 days with the message “This scheduled workflow is disabled because there hasn’t been activity in this repository for at least 60 days”. There is no notification to alert that this has happened. There should be some kind of notification. It cannot be assumed that because a repo has not been touched in 60 days, its workflow is deprecated.


There is a warning email that is sent to the repository admin 7 days before a workflow is disabled. There is also an email sent immediately after the workflow is disabled. I’ve seen feedback where the email notification is not sufficient (many users don’t actively check their emails or it gets lost among other email). That’s a perfectly valid criticism and we would like to improve this but we just haven’t gotten around to this currently given other priorities.

The reason we disable workflows in inactive repositories is so that we can continue to offer actions for free :slight_smile: I’ve seen many forked repositories for example where scheduled workflows are enabled and then there isn’t any new activity afterwards. Scheduled workflows in inactive repositories can significantly waste compute resources which can negatively impact other legitimate repositories and workflows (as an example it can take longer for a workflow to start if there are a lot of other workflows queued at the same, we don’t have unlimited capacity :wink: ).


@konradpabjan Thanks for your reply. I must have missed the emails. It would be good to have the notification email sent to a list of users. Does the notification appear in the GitHub notifications UI?


only 6 month how i will till a long to be gett contributor? hahah

The notification does not show up in the notifications UI. Currently we only have web notifications for approvals (a workflow is protected by an environment and required an approval) or when a workflow succeeds or fails (the default settings is for notifications to be sent only when a workflow run fails). There are currently no other web notifications.

The disabled notifications are easy to miss since only the repository owner gets the notification. There is some work we would like do to around notifications such as allowing users to subscribe to a scheduled workflow (same issue, only one person gets a notification if it fails or succeeds and right now it’s not very obvious who that one user is). This would certainly fail under the same category of improvements where any subscriber to the scheduled workflow would get the warning/disabled notification.

Lots of things we would like to do, but so many other priorities :grinning_face_with_smiling_eyes: We hear you feedback loud and clear though :slightly_smiling_face:

What counts towards “activity” here? Is it only commits?

What happens when a workflow is automatically disabled? Can it still be triggered manually?

1 Like

Currently any Git activity on the main branch counts. This will probably be expanded soon though to include any Git activity on any branch in the repository. The last time the workflow was enabled/disabled is also considered (60 days). So if there is no git activity but a workflow was re-enabled manually less than 60 days ago the workflow won’t be disabled yet.

Only scheduled workflows are automatically disabled, but if there there is a workflow_dispatch trigger in addition to a scheduled workflow trigger the button to let you kick off the workflow manually will be gone (the workflow behaves like a normal manually disabled workflow). There would be a banner that says the workflow is disabled due to inactivity and with one click it could be re-enabled. Afterwards the button to kick off workflows manually will appear again.

1 Like

Interesting. I’m using a workflow to only handle issues in a repository and labeling of the issues. There is no activity on any branch. Therefor my workflow is disabled every 60 days :-(.

Seriously considering adding a workflow that checks the 60 day period and just add an empty commit to a temp branch then, just to keep the workflow alive :cry: (note: I won’t do that on the default branch since that would break my fork where this is running in).

I am an admin of a repo (via a team), and none of my team were notified about our workflow being disabled? Is this a bug, or expected behaviour?

I just created an open-source GitHub action that prevents GitHub from suspending your corn job-based triggers. You can check it out here: GitHub - gautamkrishnar/keepalive-workflow: GitHub action to prevent GitHub from suspending your cronjob based triggers due to repository inactivity

Haha, it’s sad that this is necessary, but I was looking for someone to suggest doing exactly this. :slight_smile: Nice.

1 Like