Automatically Stop Scheduled n8n Workflows after "X" Time

Hi,
I’m currently using an enterprise-enabled n8n instance with multiple workflows that rely on Schedule Triggers. These workflows are created for different purposes and are configured to run at various intervals (for example, every few hours, every 24 hours, etc.).
As the number of workflows has grown, I’m looking for a way to centrally control or disable these scheduled executions…………..ideally through an environment variable or a global configuration setting.
Is there an existing mechanism in n8n to manage or pause scheduled workflows at a global level?
If not, are there any recommended patterns or best practices to handle this use case?
Any guidance would be appreciated.

Information on your n8n setup

  • n8n version: 1.123.0
  • Running n8n via (Docker, npm, n8n cloud, desktop app): Docker
  • Operating system: Linux
  • Hosted: Self

Hi @AvgCorporateSurvivor
n8n does not currently offer a built-in environment variable or global configuration setting to centrally disable all scheduled workflows. However, several effective patterns exist to manage this requirement.

But, you can create a data table called workflowmanager.
Create 2 fields:
action (string)
value (boolean)
and create a new row as follows.

Attache Data Table (Get rows) node to all workflows, right after your Triggere node.

If you have set the enable_all to false
All your workflows will stop an itteration at Data Table Node.
And if you will have it as true the execution will continue.

1 Like

Hi @AvgCorporateSurvivor,

You can create a workflow which keeps your scheduler workflow IDs in a data table and then you can use a webhook to control whether those workflows are active or not by using these nodes:

2 Likes

Hey thanks for the replies! @Wouter_Nigrini @Nayan_Thakor

These mean, Users should be adding the above “stopping nodes” additionally while configuring the workflow right?

For example, if there is a situation where a self hosted instance is being used by multiple “Users”, for testing purposes for some X reason, then, we are not sure all the users will follow the above approach right? :slight_smile:

Hi @AvgCorporateSurvivor,

Apologies but I am struggling to understand your question. Can you please elaborate a bit more on your use case? What is it that you are trying to achieve?