Skip to main content
This section describes the YAML configuration format for scheduling and managing automated tasks. The configuration supports various execution modes including scheduled runs, trigger-based execution, CI/CD integration and API, plus additional configurations like deferred artifacts (dbt™️ defer), notifications and Self-Healing.
💡 Looking for complete examples? Jump to the Example Configurations section below.

​
Base configuration

Every scheduler configuration must include these basic fields:
environment takes the slug of a Bolt environment, which determines the warehouse connection and target the run uses. production is the slug of the default environment in existing workspaces; find every environment’s slug in Settings > Environments.

​
Continue on error

By default, when a command fails the remaining commands in the schedule are skipped. Set continue_on_error to change that, either for the whole schedule or per command:
  • continue_on_error at the schedule level sets the default for every command. Defaults to false (a failure skips the remaining commands).
  • Each commands entry is either a bare string or an object with exactly two keys: command and continue_on_error. The per-command flag overrides the schedule default; omit it to inherit.
  • A failed command still marks the run as failed, even when the remaining commands run.
Retries preserve these settings: when you retry a run from failure, each retried command keeps its original continue-on-error behavior.

​
Execution modes

​
Scheduled

Basic scheduled execution using cron expression:

​
Run completion trigger

Runs this schedule after another schedule finishes:
Bolt accepts on with or without quotes. Keep the quotes if you validate the file with a Paradime CLI older than 6.9.0, which reads a bare on as the boolean true and rejects the file. The examples on this page keep the quotes: "on": [passed, failed].
schedule_trigger still works and means the same thing. A schedule can have one of run_after or schedule_trigger, not both. The Paradime CLI and Python SDK validate run_after and concurrency from version 6.8.0:
To build a chain that runs on the same pull request or merge, point a Turbo CI schedule at another Turbo CI schedule, or any schedule at an on-merge schedule.

​
Merge trigger

Triggers execution on merge events:
The schedule runs only when the pull request’s target branch is exactly its git_branch, and each run builds the pull request’s merge commit. With concurrency: queue, merges run the schedule one at a time, in the order they merged. An older merge that arrives after a newer one already had its turn is skipped, because the newer merge commit contains its changes. queue is allowed only with trigger_on_merge: true. See Merge queue.
Requires GitHub integration.

​
Turbo CI

Configuration for CI pipelines, triggered when a Pull Request is opened:

​
API (Off)

Basic configuration when triggering Bolt via API:
For more details on Paradime APIs check our Developers guide.

​
Suspended state

Configuration for suspended jobs:

​
Deferred artifacts

Any schedule can defer to the artifacts of another schedule’s run, enabling state-based selectors like state:modified+ and source_status:fresher+. This is not an execution mode — it works alongside any trigger type (cron, merge trigger, run completion or API).
💡 deferred_schedule_slug can reference the schedule itself. A self-referential deferred schedule compares against the artifacts of its own previous run — useful for incremental patterns like building only models with fresher sources.

​
Defer to an environment

Set defer_environment_slug instead of deferred_schedule_slug to compare against the latest runs of the schedules in a Bolt environment rather than one schedule. Turbo CI schedules and the schedule itself don’t count. It works in turbo_ci and in deferred_schedule. Set one target, never both.
Use the environment’s slug: it’s shown next to the environment’s name in Settings > Environments. A schedule saved from the UI writes the display name as a comment, for example defer_environment_slug: drifting-theri-oor5el # Production. paradime bolt verify accepts defer_environment_slug from Paradime CLI 6.9.0. See Defer to an environment for how Bolt picks the run.

​
Environment variable overrides

Set or override environment variables for a single schedule using env_overrides. The overrides are scoped to that schedule’s commands only — they don’t affect other schedules or your Bolt-level environment variables.
Each entry takes a key and a value. Values can be either a literal string or a reference to an existing Bolt-level environment variable using ${VAR_NAME} — useful when you want one schedule to point an existing variable like DBT_TARGET at a different value managed in your Bolt environment. Example: literal value
Example: reference an existing Bolt-level env var
Validation rules
  • key must match the pattern ^[a-zA-Z_][a-zA-Z0-9_]*$ (letters, digits and underscores; cannot start with a digit).
  • value cannot contain whitespace.
  • A ${VAR} reference that points to a Bolt-level variable that doesn’t exist is dropped silently (a warning is logged) — the schedule still deploys.
  • Entries with an invalid key or value are skipped with a warning — they will not break the deploy.
💡 If both a Bolt-level env var and an env_overrides entry define the same key, the schedule-level override wins for that schedule’s commands.

​
Notifications configuration

Notifications can be configured for various events through multiple channels:
For Slack and MS Teams notifications, check our integrations guide:
  • Slack
  • Microsoft Teams

​
Self-healing

When a schedule run fails, Paradime can automatically trigger a DinoAI agent against the failure. The agent reviews the run, implements a fix, and opens a pull request for your team to review. The session is readable in Agent Studio, and threads into a Slack channel when one is configured.
Validation: if enabled: true is set with a slack_channel, that channel must also be listed in this schedule’s notifications.slack_channels. The deployer rejects the schedule with self_healing.slack_channel '<channel>' must also appear in notifications.slack_channels otherwise, because the agent reuses the failure-notification thread and so the notification has to exist for the agent to find it. Omitting slack_channel avoids this rule entirely: the agent runs without a thread and the session is read in Agent Studio.
Example: Self-Healing alongside notifications
When this schedule fails, the failure posts to both #agent-demo and #data-alerts. The agent then runs in-thread in #agent-demo, and #data-alerts receives a courtesy 🦖 Self-healing started in #agent-demo pointer.

​
Trigger integration

You can set up triggers to automate actions when runs complete. Trigger Settings allow you to connect Bolt to external tools and services, enabling automated workflows based on your pipeline execution results.

​
Example: complete configuration

​
Best practices

Schedule Format
  • Use standard cron expressions for scheduling
    • ✅ Standard cron to define days 0-6
      • 10 * * * 0-6 : At minute 10 on every day-of-week from Sunday through Saturday.
    • ❌ Non-standard cron to define days 1-7
      • 10 * * * 1-7 : At minute 10 on every day-of-week from Monday through Sunday
  • Use 'OFF' to disable scheduled execution
  • Use crontab.guru to validate your cron expressions
SLA Configuration
  • sla_minutes should be set based on job complexity Consider dependencies when setting SLA
  • Recommended minimum: 30 minutes
Notification Configuration
  • Configure at least one notification channel
  • Include critical events (failed, SLA) in notifications
  • Use team channels for collaborative workflows
  • Make sure to set the Slack / MS Teams Channel or Email for System notifications. Check our guide here for Notifications Settingss

​
Paradime schedules terminal commands

Before running any of the following commands, navigate to your dbt™️ project directory where paradime_schedules.yml is located.