Skip to main content

Scheduled runs

Schedule Hex apps to re-run on a set schedule — hourly, daily, weekly, or monthly intervals.

Scheduled runs do two important things:

  1. Execute the entire project's Logic top to bottom.
    • This means any side effects of running the project (a database write-back, an API call, a webhook ping, etc.) will occur.
  2. Update the cache of the published app, used for the initial state a user sees opening the app.
tip

Scheduled runs may be delayed up to 60 seconds. This is done for reliability at times when many jobs may be scheduled to run simultaneously.

Access scheduling options through the Scheduled run button in the left-hand sidebar, where you can configure new schedules as well as view historical scheduled runs and whether they succeeded or failed.

For any scheduled run, you can view the historic state of the app at runtime by selecting the specific run.

caution

Important: scheduled runs operate on the currently published version of the logic, which may differ from the version you're viewing. Learn more about published versions here.

Scheduled runs and caching#

When an app performs a scheduled run, the default state of the published app is updated with the results of the run. If the cache default state option is on, subsequent visitors to the app will see the cached values set during the scheduled run. App users can still re-run the app manually at any time to see freshly generated outputs (with the exception of SQL cells that are cached on a schedule). These manual runs will not update the cache for any other user of the app, and will not persist if the user refreshes the page.

This can be useful for computationally expensive apps that take a long time to run and do not need to be updated multiple times per hour. Regardless of how long the Logic of an app takes, cached results will appear almost instantly.

Scheduled run variable#

The built-in hex_scheduled variable is a boolean that evaluates to True while executed as part of a scheduled run. For example, this could be used so that a database write-back is only triggered on a scheduled run, and not as part of an ad hoc usage of an app.

This can be useful for workflows with long-running or computationally expensive query steps, so the app is more responsive for end users. This can be achieved using a similar pattern to:

if hex_scheduled:    ## expensive query step    ## write results out to a file or databaseelse:    ## read from written file or database

The hex_run_context variable allows you to detect if a run is occurring in a logic session or as part of an app run. It will always evaluate to either logic or app.

if hex_run_context == "logic":    ## Something that only needs to happen during a manual Logic runelse:    ## something that should happen as part of app runs