Skip to main content
The trigger defines when a Bolt schedule runs. It is the first thing you configure when creating a schedule: pick a trigger type, then add commands, schedule settings, and notifications.

​
Trigger types

​
Scheduled

Runs the schedule automatically on a cron schedule.
  1. Select Scheduled as the trigger type.
  2. Enter a cron schedule (for example, 0 0 * * *). Use Choose a preset for common intervals, or Cron help to build your own.
  3. Select a timezone. The default is UTC.
For help writing cron expressions, use the Choose a preset dropdown, or visit crontab.guru.

​
On run completion

Runs the schedule after another Bolt schedule finishes, so you can chain dependent workflows, including across Paradime workspaces.
  1. Select On run completion as the trigger type.
  2. In the Workspace Name dropdown, select the Paradime workspace that contains the triggering schedule.
  3. In the Bolt Schedule Name dropdown, select the schedule that acts as the trigger.
  4. Choose which parent outcome starts this run:
    • Passed: only when the parent schedule completes successfully.
    • Failed: only when the parent schedule completes with errors.
    • Passed & Failed: whenever the parent schedule completes, regardless of outcome.
A parent run on a different git branch from its schedule’s own branch doesn’t start this schedule. This covers an API, CLI, or DinoAI trigger with a custom branch or commit, and a retry of such a run. For a parent schedule with no branch set, the workspace’s default branch counts as its own. The parent’s run page shows a Branch override pill. This keeps one chain from running two versions of your code.
A Turbo CI run doesn’t start schedules that run after it. They start only after the parent’s scheduled, manual, or API runs. To run a schedule after a Turbo CI schedule on the same pull request, use the Turbo CI trigger with Run after another schedule instead.

​
On merge

Runs the schedule when a pull request is merged into the branch, for continuous deployment workflows.
Prerequisite: GitHub integrationParadime must be connected to your GitHub repository with the GitHub App installed so it can detect merge events on the branch.Using another Git provider? Use the CI/CD code templates to run on merge.
  1. Select On merge as the trigger type.
  2. Optionally, turn on Run after another schedule to make this schedule a later step of a merge chain.
  3. Under When merges overlap, choose what happens when a merge arrives while this schedule is still running for an earlier one:
    • Run in parallel (default): each merge starts its run straight away.
    • Wait in line: one run at a time, in the order the pull requests merged. See Merge queue.
  4. Click Deploy to publish the schedule.
The schedule runs only when the pull request’s target branch is exactly the schedule’s branch, and each run builds the pull request’s merge commit.

​
Turbo CI

Runs the schedule when a pull request is opened, building only the changed models so you can validate changes before they merge. See Turbo CI for the full setup, including per-provider configuration and schema cleanup. A workspace can have several Turbo CI schedules. Turn on Run after another schedule to run one after another on the same pull request.

​
Run after another schedule

The Turbo CI trigger with Run after another schedule turned on, CI-pre-commit picked as the Bolt schedule name, and Passed selected
On the Turbo CI and On merge tabs, Run after another schedule makes the schedule a later step of a chain, so it runs on the same pull request or merge once the schedule before it finishes.
  1. Turn on Run after another schedule.
  2. In Bolt schedule name, pick the schedule to run after. Only schedules in the current workspace are listed. For a Turbo CI schedule, pick another Turbo CI schedule.
  3. Under Bolt schedule complete with status:, pick Passed, Failed, or both.
Chains need the Paradime GitHub app.

​
Incoming webhook

Runs the schedule when an external tool, such as Jira Automation, Zapier, or a CI job, sends a POST request to one of the schedule’s incoming webhooks. The app lists each one as a Trigger URL.
  1. Deploy the schedule first. A new schedule shows its Trigger URLs card once it’s deployed.
  2. Edit the schedule and select Incoming webhook as the trigger type.
  3. In the Trigger URLs card, click New Trigger URL, name the webhook, and copy the URL and secret it shows.
A Bolt schedule's Trigger type section with Incoming webhook selected, and the Trigger URLs card listing one webhook URL with Deliveries, an on switch, Send test request, Rotate, and Delete
See Incoming webhooks for how to call the webhook, check each request it receives, and pause or rotate it.

​
Off

No automatic trigger. The schedule only runs when you start it manually or call it through the Paradime API. Use this for on-demand schedules and for triggering Bolt from external systems such as Airflow, Dagster, or Prefect.
  1. Select Off as the trigger type.
  2. Run the schedule manually from the Bolt UI, or trigger it with the Bolt API.
Next, configure the commands your schedule runs.

Define this as code

Set the trigger in YAML with schedule, run_after (or schedule_trigger), trigger_on_merge, or turbo_ci.