Managing App Schedules | MuleSoft Documentation
# Managing App Schedules
You can use Runtime Manager to view and control the Scheduler components within the flows in your deployed applications, all without changing the running application. For example, you might want to disable a scheduled job while one of the applications is undergoing maintenance.
On the **Schedules** tab, you can:
  * View the schedules in your running application.
  * Change the schedules in your application.
  * Run the scheduled job immediately, without changing the schedule.
  * Disable or enable the schedule for a flow.


You configure Scheduler component types as either _fixed frequency_ to trigger at a regular interval or _cron_ to trigger at a date and time based on a specified cron expression.
To change a schedule type (between fixed frequency and cron or vice versa), you must update and redeploy the app. You can’t change the schedule type on a deployed application.   
---  
To view the application schedules, you must have the **Exchange Viewer** permission, in addition to the **Read Applications** permission.   
---  
## Schedule Design Considerations
When designing the schedule, consider the following:
  * Plan for high availability during network failures. The CloudHub 2.0 infrastructure restarts due to hardware issues or scheduled maintenance, and security updates.
During service updates or security patching, CloudHub 2.0 waits five minutes for existing schedules to complete. After a new replica is launched, the schedule runs at its next scheduled time. For more information, see the `shutdownTimeout` attribute in Global Configurations Reference.
  * After a security patching, the custom configuration via Runtime Manager takes precedence over the application configuration file.
You can reset the schedulers and delete the custom configuration via API:
```
DELETE /organizations/{organizationId}/environments/{environmentId}/deployments/{deploymentId}/schedulers/{flowName}
```

  * Because schedules can be triggered more than once, design them to prevent duplicate data processing. If clustering is enabled, CloudHub 2.0 executes the schedule on a single replica, regardless of how many replicas are running. Subsequent schedule executions can occur on a different replica. CloudHub 2.0 distributes multiple concurrent schedules across replicas.
  * For clustered applications, CloudHub 2.0 triggers the schedule exclusively on the primary node.
  * If clustering isn’t enabled, schedules run individually on all replicas.
  * For a fixed-frequency scheduler, the minimum recommended start delay is five seconds. For more information, see Disable or Enable a Scheduler Element.
  * If a schedule isn’t executed because the application isn’t running, CloudHub 2.0 doesn’t trigger it immediately when the application starts. The schedule is executed at its next scheduled time.
  * The CloudHub 2.0 scheduler reads the job configuration every time it runs.
When you update the scheduler configuration, the change takes effect the next time the scheduler runs.
  * Changing the schedule redeploys your application.
  * If you scheduled a job for a time that is in the past while your app isn’t running, the job doesn’t execute when your app is started.
  * Schedules are based in the scheduler’s defined time zone.
  * For multi-replica apps, CloudHub 2.0 runs scheduled jobs on all replicas.
If you run the scheduled job immediately by clicking **Run** , the scheduler runs on a single replica.
CloudHub 2.0 distributes multiple concurrent schedulers across replicas.
  * You can’t manage CloudHub 2.0 schedules using scripts.
Use the **Schedules** tab or the CloudHub 2.0 API to manage CloudHub 2.0 schedules.
  * Flow names can contain only upper and lower case letters, numbers, hyphens (`-`), underscores (`_`), and periods (`.`). The following characters are invalid: `/`, `[`, `]`, `{`, `}`, and `#`.
  * CloudHub 2.0 schedules run concurrently by default. The Scheduler triggers the execution of a schedule flow while a previously-triggered execution is still running. To run schedules sequentially, set the `disallowConcurrentExecution` property as `true` in the scheduler configuration file.
  * By default, schedulers use the same time zone as the machine on which Mule is running. You can change it by adding the time zone you want. For more information, see code-builder::acb-component-scheduler.adoc.


## Before You Begin
To use the scheduling feature in Runtime Manager, deploy an application that includes one or more Scheduler elements using Anypoint Studio 7.13 or later.
After you deploy the app, you can manage the schedule in Runtime Manager. The app doesn’t need to be running.
## View and Manage Application Schedules in Runtime Manager
After deploying an app to CloudHub 2.0, view and manage the Scheduler elements in Runtime Manager:
  1. From Anypoint Platform, select **Runtime Manager** > **Applications**.
  2. Click the app name.
  3. In the navigation menu, click **Schedules**.
Runtime Manager lists the Scheduler elements in the order they appear in your app:
     * The **Name** column shows the name of the flow (1) that contains the Scheduler element.
     * The frequency link (2) in the **Schedule** column shows the schedule for the element.
  4. If you want to see more information about when the jobs started and ended, click **Logs** in the navigation menu:
  5. Click the frequency link for an element to open the schedule editor.
The schedule editor you see depends on the schedule type:
     *   6. In the schedule editor, change the schedule or deselect **Enabled** to disable the schedule.
  7. Click **Update** to save changed settings or click **Cancel** to exit without saving.


### Change a Fixed Frequency Schedule
  1. From Anypoint Platform, select **Runtime Manager** > **Applications**.
  2. Click the app name.
  3. In the navigation menu, click **Schedules**.
The **Schedule** column shows the schedule for the element:
  4. Click the frequency link for an element to open the schedule editor.
  5. In the schedule editor, change the schedule or deselect **Enabled** to disable the schedule:
You can specify milliseconds, seconds, minutes, hours, or days for the frequency. The minimum recommended frequency between calls is 10 seconds.
By default, schedules run at the frequency defined in the application. When you change the frequency of a schedule from Runtime Manager, the schedule runs at the frequency configured in Runtime Manager even if you update and redeploy the same schedule in the application JAR file.   
---  
  6. Click **Update** to save changed settings or click **Cancel** to exit without saving.


### Change a Cron Schedule
With cron expressions, you can create more complex schedule frequencies, such as every 5 minutes between 9:00 am and 10:00 am on Fridays.
To change the frequency of a cron schedule type:
  1. From Anypoint Platform, select **Runtime Manager** > **Applications**.
  2. Click the app name.
  3. In the navigation menu, click **Schedules**.
The **Schedule** column shows the schedule for the element:
  4. Click the frequency link for an element to open the schedule editor.
  5. In the schedule editor, change the schedule or deselect **Enabled** (1) to disable the schedule:
  6. In the schedule editor, select the time zone for your schedule from the **Time Zone** (3) dropdown menu.
  7. In the schedule editor, click **Quick Reference** (3) to expand or collapse the table that lists required fields and allowed values.
The cron expression in this example sets the schedule to every 10 seconds.
For information about building cron triggers:
    1. View the Quartz documentation.
    2. Select a version, click **Documentation > User’s Guide > Tutorial**, and then click the **CronTrigger** lesson.
  8. Click **Update** to save changed settings or click **Cancel** to exit without saving.


## Run a Scheduled Job Immediately
If a job runs nightly but you want to debug it now, you can trigger the job while it’s running without updating the schedule in your application. When you trigger the job in between instances of the scheduler running, the timer for the indicated time period resets.
If you run the scheduled job immediately, the scheduler runs on a single replica even for multi-replica apps.   
---  
To override the schedule and run the job immediately:
  1. From Anypoint Platform, select **Runtime Manager** > **Applications**.
  2. Click the app name.
  3. In the navigation menu, click **Schedules**.
  4. Select the elements to manage and then click **Run**.
## Run a Scheduled Job Immediately
If a job runs nightly but you want to debug it now, you can trigger the job while it’s running without updating the schedule in your application. When you trigger the job in between instances of the scheduler running, the timer for the indicated time period resets.
If you run the scheduled job immediately, the scheduler runs on a single replica even for multi-replica apps.   
---  
To override the schedule and run the job immediately:
  1. From Anypoint Platform, select **Runtime Manager** > **Applications**.
  2. Click the app name.
  3. In the navigation menu, click **Schedules**.
  4. Select the elements to manage and then click **Run**.


## Disable or Enable a Scheduler Element
You might want to disable a scheduled job if an application you are connecting to is undergoing maintenance and then reenable it after maintenance is complete.
CloudHub 2.0 does not run the scheduled job until you reenable the Scheduler.
**Known issue** : If you disable the scheduler, it still runs when starting an application. If you want to prevent the scheduler from running, set the `startdelay` property to five seconds in your app using Anypoint Studio.
To disable the Scheduler element:
  1. From Anypoint Platform, select **Runtime Manager** > **Applications**.
  2. Click the app name.
  3. In the navigation menu, click **Schedules**.
  4. Select the elements to manage and then click **Disable**.
You can also disable or enable the schedule by deselecting or selecting **Enabled** in the schedule editor.


## Schedule Behavior with Rolling Update vs. Recreate Deployment Model
During the initial deployment of an application with cluster mode and rolling update deployment model enabled, the application’s fixed-frequency scheduler runs alongside the application startup. If you switch from rolling update to recreate deployment model, the scheduler is triggered again with the application startup. But if you switch from recreate back to rolling update deployment model, the scheduler no longer runs at startup and instead triggers based on the configured frequency.
This happens because the recreate deployment model turns off the previous instances of the application and starts them again in a new cluster. The previous record of the last run of the scheduler isn’t saved. In this case, Mule runs the scheduler unless it’s a fixed-date frequency. However, the rolling update deployment model saves the previous configuration.
## See Also
  * Deploying Apps to CloudHub 2.0
  * Scheduler Endpoint (Trigger)
  *   * Example Assets provided by MuleSoft