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

Triggers execution based on completion of another job:

​
Merge trigger

Triggers execution on merge events:
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.

​
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 inside the configured Slack thread. The agent reviews the run, implements a fix, and opens a pull request for your team to review.
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 — the agent reuses the failure-notification thread, so the notification has to exist for the agent to find it.
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.

Related topics

YAML ConfigurationTriggering from BoltMigrate Turbo CI from --target flags to a CI environmentManage schedules as codeAPI Reference