Skip to main content

Running actions on a schedule

Interval supports running actions on a fixed schedule. For example, you might build an action to sync data with an external service that runs every night. This functionality can be thought of as an extremely user-friendly alternative to writing cron scripts.

Scheduled transactions are currently in alpha. Contact us if you'd like to be added to the alpha.

Supported schedules

Actions may be scheduled to run:

  • Hourly
  • Daily
  • Weekly
  • Monthly

Handling errors and requesting input

Sometimes, you'll want to throw an error from an action. Just like other actions, when an error occurs, you'll automatically be notified.

Additionally, if your scheduled action requests input via an I/O method, you'll be notified so that you can provide input.

Being able to collect input from a scheduled action makes Interval an extremely powerful tool for cron-style workflows. Traditionally, when an unexpected condition is encountered during the execution of a cron job, you would stop execution, manually resolve the issue and re-run your job.

With Interval, when an unexpected condition is encountered, you can use an I/O method to collect input that resolves the issue, allowing your scheduled action to complete successfully.

Consider this example that syncs data from an external service every night:

import Interval, { io } from "@interval/sdk";

const interval = new Interval({
apiKey: "<YOUR API KEY>", // get an API key at
actions: {
sync_data: async () => {
const data = await fetch("<some_external_url>").then(resp => resp.json());

for (let row of data) {
if (! {
const [, email] = await[
## An issue was encountered syncing data.
No email was present in the row, provide an email before continuing.
`),"Enter an email:"),
]); = email;
// Now every row is guaranteed to have an email
// We can insert the row into our app's database


Specifying a runner

By default, the owner of your organization is listed as the runner of any scheduled transaction. Optionally, you may set another user in your organization as the runner.

In most cases, this isn't important. However, the person you choose:

  • Receives notifications when an error occurs, the transactions completes, or requires input.
  • Is listed as the runner in your organization's transaction history.
Was this section useful?