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:
Execution Modes 1. Schedule-Triggered Execution Basic scheduled execution using cron expression:
2. Run Completion Trigger Triggers execution based on completion of another job:
3. Merge Trigger Triggers execution on merge events:
Requires GitHub integration.
4. Turbo CI Configuration Configuration for CI pipelines, triggered when a Pull Request is opened:
5. API Configuration Basic configuration when triggering Bolt via API:
For more details on Paradime APIs check our Developers guide.
6. Suspended State Configuration for suspended jobs:
Deferred Artifacts (dbt™ defer) 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

Triggering from Boltbolt-ci-healerBolt Pipeline HealerTools ReferenceAPI Reference