Scheduling

You can schedule Hex apps to re-run on a set schedule, at Hourly, Daily, Weekly, or Monthly intervals. Scheduled runs of Hex apps do two important things:

  1. Scheduled runs 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. Scheduled runs update the cache of the published app, which is used for the initial state a user sees when visiting the app.

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 Schedule options through the sidebar on the left, 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 at runtime using the arrow on the right.

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 pattern like the below:

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

The $hex_run_context variable similarly 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 run
else:
## something that should happen as part of App runs