Skip to main content

Scheduled runs & notifications

Set up scheduled runs and configure email or Slack notifications with App screenshots.

info
  • Available on the Team and Enterprise plans.
  • The Professional plan is limited to 1 scheduled run per project and does not include Slack notifications or custom schedules.
  • Users will need Can Edit or higher project permissions to manage scheduled runs.

Hex apps can be configured to be run on a schedule at whatever cadence makes sense for your use case. When a scheduled run succeeds, the entire project's logic is run from top to bottom, executing any queries and writebacks, running all code, and updating any outputs displayed in your app. Scheduled runs can also be used to update what users see when initially opening an app.

Access scheduling options through the Scheduled runs tab in the left sidebar. Here you can configure schedules as well as view details about past runs via the Run log. For any scheduled run, you can view the historic state of the app at runtime by selecting the specific run. Note: scheduled runs may be delayed up to five minutes. This is done for reliability at times when many jobs may be scheduled to run simultaneously.

Schedule Runs

You can schedule apps to run on hourly, daily, weekly or monthly intervals.

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 Run Notifications

When creating a scheduled run, you have the option to configure notifications for run successes and failures, as well as which users will receive those notifications. You can create multiple scheduled runs for a given project, each with its own notification settings.

Notify users or groups

To send scheduled run notifications to a user or group, click the + Add Notification button and select Send to users or groups. By default, this will notify the selected users via email. Users can configure their personal notification preferences to recieve scheduled run notifications from the Slack Hex app instead of email, or from the Slack app and email.

tip

Personal Slack notifications are only sent to individual Slack users via the Hex Slack app and are separate from Slack channel notifications outlined below.

Select the option for when you'd like to send the notification, and check the Include screenshot box if you'd like for the notification to include an embedded screenshot (PNG or PDF) for successful app runs.

To receive scheduled run notifications, a user must have App Only project permissions or higher. If you attempt to set notifications for a user or user group that does not have access to the project, the user(s) will automatically be granted App Only access.

Notify a Slack channel

To use Slack notifications, an Admin will first need to need to configure the Hex Slack integration from Settings > Integrations.

Then any user with Can Edit project permissions can configure a scheduled run notifications to Slack channels in their workspace.

The first time you set up a Slack notification by selecting the Send to Slack channel option, you'll be prompted to authorize your personal Slack account with the Sign in button.

You can also authorize your personal Slack account from the Settings > Notifications.

Once your Slack account is connected to Hex, you can choose your Slack notification trigger (scheduled run success, failure, or both) and optionally enable the Include screenshot setting if desired. Lastly, select which Slack channel or channels you'd like to send the notification to.

If you'd like to send a scheduled run notification to a private Slack channel, you'll need to add the Hex Slackbot to the private channel and refresh the page where you are configuring the schedule.

Scheduled runs and caching

If your app is set to show results from a previous run when an app user opens the published app, subsequent visitors to the app will see the app output of the most recent scheduled run or publish. 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 database
else:
## read from written file or database

The hex_run_context variable is more granular and allows you to detect the specific run context of the app run. This variable will evaluate to logic, app, scheduled, or api-triggered.

if hex_run_context == "logic":
## something that only needs to happen during a manual Notebook run
else:
## something that should happen as part of app or scheduled runs

Files created in scheduled runs

Files created and written to a project's file directory during scheduled jobs or published app sessions are not persisted between scheduled runs. This means that any files written out by a scheduled job cannot be accessed in the Notebook view, App builder, or in future scheduled runs of the project. For example, a file saved using to_csv in a Python cell can only be read back in during the same scheduled run.

If you need to persist files between scheduled runs, we recommend writing the data to an external source, such as your database, S3, or Google Drive. Then, you can read this data back in during future runs of the project, including scheduled runs and published app runs.