---
schema_version: "1"
id: 931f60c0f1be00824f38efba9b015f93bbf7932e1e6cbd0097bea31ca63a6064
title: Managing App Schedules
collection: mulesoft
version: current
locale: en-us
portal_url: https://docs.salesforce.com/mulesoft/current/en-us/cloudhub-2/ch2-manage-schedules.md
canonical_url: https://docs.mulesoft.com/cloudhub-2/ch2-manage-schedules
source_site: docs.mulesoft.com
content_type: documentation
content_hash: 35ac26f05cd0116c735a298bba10b59c838323e61b15b477bb5d6cf38ce70795
description: MuleSoft Documentation Site
latest: true
---
---
product: CloudHub 2.0
---

# Managing App Schedules

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

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.

> [!NOTE] The CloudHub schedules REST API doesn’t expose scheduler or domain details for CloudHub
> 2.0 applications. Manage CloudHub 2.0 schedulers only through the CloudHub 2.0 APIs or the Runtime
> Manager **Schedules** tab.

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.

> [!IMPORTANT] 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.

> [!IMPORTANT] 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](https://docs.mulesoft.com/mule-runtime/latest/global-settings-configuration#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:

  ```curl
  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](#disable-enable-scheduler).

- 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](https://docs.mulesoft.com/mule-runtime/latest/scheduler-concept#props_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
  [Cron Expressions](https://docs.mulesoft.com/anypoint-code-builder/acb-component-scheduler#cron-expressions).

### Fixed Frequency Schedules in Cluster Mode During Rolling Restart

These transition behaviors apply to fixed-frequency schedules when the application runs in cluster
mode and undergoes a rolling restart.

Polling node transition and first trigger

During a rolling restart, CloudHub 2.0 starts new nodes before it removes old nodes. The cluster
elects a new polling node only after it decommissions the previous polling node. The new node then
triggers the schedule. Until this election completes, no node polls the schedule. As a result, the
first trigger that would otherwise occur right after a new node starts doesn’t fire. The schedule
runs at the next calculated time after the cluster elects the new polling node.

Schedule timing after restart

Fixed-frequency schedules don’t retain the original schedule anchor after a rolling restart. The
scheduler calculates the next run time relative to when the cluster elects the new polling node, not
the pre-restart cadence. CloudHub 2.0 doesn’t support retaining the original schedule timing for
fixed-frequency schedules.

## 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.

![Scheduler component in the Anypoint Studio canvas](/mulesoft/current/en-us/cloudhub-2/_images/ch2-scheduler-studio.png)

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:

    ![(1) Flow name and (2) the frequency link on the Schedulers page.](/mulesoft/current/en-us/cloudhub-2/_images/ch2-scheduler-rtm.png)

    - 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:

    ![Logs option in the navigation menu.](/mulesoft/current/en-us/cloudhub-2/_images/ch2-logs-rtm.png)

5.  Click the frequency link for an element to open the schedule editor.

    The schedule editor you see depends on the schedule type:

    - [Fixed frequency](#change-fixed-frequency-schedule)

    - [Cron](#change-cron-schedule)

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:

    ![Fixed frequency schedule type](/mulesoft/current/en-us/cloudhub-2/_images/ch2-scheduler-fixed-rtm.png)

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:

    ![Fixed-frequency schedule configuration](/mulesoft/current/en-us/cloudhub-2/_images/ch2-scheduler-editor-fixed.png)

    You can specify milliseconds, seconds, minutes, hours, or days for the frequency. The minimum
    recommended frequency between calls is 10 seconds.

    > [!NOTE] 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.

    > [!NOTE] The `startDelay` property is not visible or configurable in the Runtime Manager UI. To
    > change the `startDelay` value after deployment, use the Schedulers API. See
    > [Override Scheduler Properties Using the Schedulers API](#override-scheduler-api).

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:

    ![cron schedule type](/mulesoft/current/en-us/cloudhub-2/_images/ch2-scheduler-cron-rtm.png)

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:

    ![cron schedule configuration with (1) Enabled option and (2)  Quick Reference link](/mulesoft/current/en-us/cloudhub-2/_images/ch2-scheduler-editor-cron.png)

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](https://www.quartz-scheduler.org/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.

## Override Scheduler Properties Using the Schedulers API

The Schedulers API enables you to override scheduler configuration properties for a deployed
application without redeploying it. This is useful for properties that are not configurable in the
Runtime Manager UI, such as `startDelay` for fixed-frequency schedules.

### Overridable Properties

Depending on the schedule type, you can override these properties:

<table><colgroup><col> <col></colgroup><thead><tr><th>Schedule Type</th><th>Overridable Properties</th></tr></thead><tbody><tr><td><div><div><p>Fixed Frequency</p></div></div></td><td><div><div><ul><li><p><code>frequency</code> - The interval between schedule executions.</p></li><li><p><code>startDelay</code> - The initial delay before the first execution.</p></li><li><p><code>timeUnit</code> - The time unit for <code>frequency</code> and <code>startDelay</code> (for example, <code>MILLISECONDS</code>, <code>SECONDS</code>, <code>MINUTES</code>, <code>HOURS</code>, <code>DAYS</code>).</p></li></ul></div></div></td></tr><tr><td><div><div><p>Cron</p></div></div></td><td><div><div><ul><li><p><code>expression</code> - The cron expression that defines the schedule.</p></li><li><p><code>timeZone</code> - The time zone for the cron schedule.</p></li></ul></div></div></td></tr></tbody></table>

### Update Scheduler Properties

To update scheduler properties, send a `PUT` request to the Schedulers API endpoint:

```curl
curl -X PUT \
  https://anypoint.mulesoft.com/amc/application-manager/api/v2/organizations/{orgId}/environments/{envId}/deployments/{deploymentId}/schedulers/{flowName} \
  -H 'Authorization: bearer {token}' \
  -H 'Content-Type: application/json' \
  -d '{
    "startDelay": "10",
    "frequency": "60000",
    "timeUnit": "MINUTES"
}'
```

Replace these placeholders in the request:

- `{orgId}` - Your Anypoint Platform organization ID.

- `{envId}` - The environment ID where the application is deployed.

- `{deploymentId}` - The deployment ID of your application.

- `{flowName}` - The name of the flow that contains the Scheduler element.

- `{token}` - A valid Anypoint Platform access token.

For cron schedules, use the `expression` and `timeZone` properties in the request body instead:

```curl
curl -X PUT \
  https://anypoint.mulesoft.com/amc/application-manager/api/v2/organizations/{orgId}/environments/{envId}/deployments/{deploymentId}/schedulers/{flowName} \
  -H 'Authorization: bearer {token}' \
  -H 'Content-Type: application/json' \
  -d '{
    "expression": "0 0/5 * * * ?",
    "timeZone": "America/Los_Angeles"
}'
```

## 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.

> [!NOTE] 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 doesn’t run the scheduled job until you reenable the Scheduler.

Even after you disable a scheduler, it can still run once. The condition that triggers a disabled
scheduler, and the way to prevent an unwanted run, depend on the schedule type:

<table><colgroup><col> <col> <col></colgroup><thead><tr><th>Schedule Type</th><th>When a Disabled Scheduler Can Still Run Once</th><th>How to Prevent It</th></tr></thead><tbody><tr><td><p>Fixed frequency</p></td><td><p>The scheduler can trigger once when the application starts.</p></td><td><div><div><p>Set the <code>startDelay</code> property to at least five seconds. Configure <code>startDelay</code> in your app in Anypoint Studio, or change it after deployment using the <a href="#override-scheduler-api">Schedulers API</a>.</p></div></div></td></tr><tr><td><p>Cron</p></td><td><p>Changing any schedule redeploys the application, and a redeployment that occurs close to the cron trigger time can let a disabled scheduler run once. Because enabling or disabling any scheduler redeploys the app, running several enable or disable actions near a cron trigger time can trigger a disabled scheduler.</p></td><td><div><div><p>The <code>startDelay</code> property applies only to fixed-frequency schedulers and has no effect on cron schedulers. Avoid enabling or disabling schedulers close to a cron trigger time, and confirm the scheduler state on the <strong>Schedules</strong> tab afterward.</p></div></div></td></tr></tbody></table>

> [!NOTE] A disabled scheduler can revert to enabled after an application restart, rolling restart,
> or maintenance, so it can run again even though you disabled it. This behavior isn’t limited to
> first startup. After a restart, check the scheduler state on the **Schedules** tab and disable it
> again if you need it to stay off.

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.

    ![Enabled toggle in the schedule editor](/mulesoft/current/en-us/cloudhub-2/_images/ch2-scheduler-enable.png)

## Schedule Behavior with Rolling Update vs. Recreate Deployment Model

For fixed-frequency schedules in cluster mode, see
[Fixed Frequency Schedules in Cluster Mode During Rolling Restart](#cluster-mode-fixed-frequency)
for transition behavior during rolling restarts, including the first trigger after node start and
schedule timing.

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](https://docs.mulesoft.com/cloudhub-2/ch2-update-apps#rolling-update-vs-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](https://docs.mulesoft.com/cloudhub-2/ch2-deploy)

- [Scheduler Endpoint (Trigger)](https://docs.mulesoft.com/mule-runtime/latest/scheduler-concept)

- [Quartz documentation](https://www.quartz-scheduler.org/documentation/)

- [Example Assets provided by MuleSoft](https://anypoint.mulesoft.com/exchange/?view=grid&type=example&search=&organizationId=68ef9520-24e9-4cf2-b2f5-620025690913)