Job Scheduling
Automate your dbt runs on any schedule. Define when models run, set dependencies between jobs, and monitor execution without leaving dbdeux.
Create Job Wizard
New jobs are built through a guided wizard that walks you from trigger to a safe preview, so you never hand-edit a job payload or guess what it will do.
Choose How the Job Triggers
Pick the trigger that fits the job instead of forcing everything onto a cron schedule:
- Scheduled: runs on a cron cadence you define
- Manual only: never fires on its own; you run it on demand with Run now. Ideal for backfills and one-off refreshes
- On merge: runs after code merges to a branch you watch
- Both: runs on its schedule and after a merge
Manual-only and on-merge jobs are never scheduled, so they will not surprise you with an unexpected cron run.
Dry-Run Preview
Before you save, run a dry-run preview. dbdeux resolves the full job on the server without persisting anything and shows you exactly what would happen: the commands, the resolved selection, how many models would build, and how many would defer. You catch a mistake before it ever touches your warehouse, not after.
Cycle-Safe Dependencies
When you chain a job to run after another, the wizard validates the dependency graph so you cannot point a job at itself or create a loop. Invalid chains are blocked at creation time.
Pick the Environment
The wizard makes it clear what the job will actually connect to. A new job pre-selects your Production environment by default, and each option spells out what it means:
- With an environment: the job runs with that environment's warehouse connection, variables, and dbt target. This is what you want almost every time
- No environment (repo
profiles.ymlonly): the job has no warehouse connection or variables, so the run only works if your repository commits a self-containedprofiles.yml. The wizard warns you to pick an environment unless you specifically need this
This removes the common surprise of a job that saves fine but fails at run time because it had no connection.
Schedule Builder
Create schedules visually without writing cron expressions:
Preset Schedules
| Schedule | Runs at |
|---|---|
| Hourly | Every hour at :00 |
| Daily | Every day at a time you choose |
| Weekdays | Monday through Friday at a time you choose |
| Weekly | Once per week on a day and time you choose |
| Custom | Any cron expression for complex schedules |
Custom Cron
For advanced use cases, enter any cron expression:
0 6 * * *- Every day at 6:00 AM0 */2 * * *- Every 2 hours0 8 * * 1-5- Weekdays at 8:00 AM0 6,18 * * *- Twice daily at 6:00 AM and 6:00 PM
Job Configuration
Each scheduled job specifies:
- Which models to run: Use dbt selectors (
tag:daily,staging.*,+dim_customers) - Run mode: Run, test, build, or a custom sequence
- dbt version: Pin a specific engine version (Core 1.8, 1.10, or Fusion) per schedule
- Environment: Which environment and connection to use (dbt variables from the environment are injected automatically)
- Timeout: Maximum allowed duration before the job is killed
- Retry policy: Automatically retry on failure (configurable attempts and backoff)
- Concurrency policy: Control whether overlapping runs queue, skip, or cancel the previous run
- Auto-deactivate: Automatically disable the job after N consecutive failures
Scheduled jobs build the dbt connection profile from the environment you select, so a run works even when the environment uses a custom target name that is not defined in your repository's profiles.yml. There is no need to keep a matching target in the repo just to make schedules run.
Per-Job Environment Variable Overrides
Beyond the variables inherited from the environment, each job can define its own variable overrides. This lets one job reuse an environment while changing a handful of values (for example a lookback window or a batch date) without cloning the whole environment.
Defer to Production
Turn on Defer to production so a job builds only what it needs while resolving everything else against your last production build (--defer --state). Selectors like state:modified or a narrow +model run fast without failing on missing upstream relations. If a usable production state is not available, the run proceeds without defer and notes that in the log rather than failing.
Two controls give you fine-grained command over how defer behaves:
- Favor deferred state: prefer the deferred (production) relation even when a stale copy exists in the job's own target schema (
--favor-state), so you always compare against trusted data - Selectable defer source: choose which environment's build to defer against, rather than always assuming production
A readiness panel tells you up front whether deferred state is available for the environment you picked, so you know the option will actually take effect before you save the job.
Source Freshness Pre-Check
Enable Check source freshness first to run dbt source freshness before the rest of the job. If upstream data is stale, you find out before spending compute rebuilding models on old inputs.
A freshness check is only as good as its cadence, so the wizard shows an SLA-aware cadence hint: it compares the job's schedule against your project's tightest source freshness threshold and warns you when the job runs less often than a source's SLA expects. That keeps a daily job from quietly reporting an hourly source as "fresh."
Ordered Steps
A single job can run more than one dbt command. Add ordered steps in the schedule builder and they execute one after another on the same worker, so you can build, test, and generate docs in a single job without wiring up separate schedules.
- The first command is always step 1; add as many follow-up steps as you need
- Steps run in the order you list them, sharing the same environment and dbt version
- The run stops at the first failing step, so a failed build never masks a later step's result
- Steps can include
dbt source freshness, so you can check that upstream data is current before the rest of the pipeline runs - Each step shows its own status chip (queued, running, passed, failed) on the run, so a multi-step job tells you at a glance exactly which command it is on and which one failed. Run logs are color-coded, and the run summary shows the target environment the job ran against
Dependency Chains
Chain whole jobs together with run after: pick another job in the same project, and a successful run of that job automatically enqueues this one. dbdeux validates the chain so you cannot point a job at itself or create a cycle.
Create pipelines where one job triggers the next:
- Extract job runs at 6:00 AM (seeds and sources)
- Transform job starts when extract succeeds (staging + intermediate models)
- Serve job starts when transform succeeds (marts and final models)
- Test job runs after serve to validate data quality
If any job fails, downstream jobs are held and you are notified immediately.
Monitoring
Recent Runs
View the complete history of scheduled runs with full filtering and sorting:
- Status filter: Show only successful, failed, skipped, or in-progress runs
- Trigger filter: Filter by trigger type (scheduled, manual, merge)
- Sortable columns: Sort by status, trigger, attempt count, created time, or duration
- Pagination: Browse through results 15 at a time with page counts
- Duration comparison against historical averages
- Sticky header: The column headers stay fixed while you scroll through long run histories
- Error details for any failures with direct links to logs
Per-Run Source Freshness and Artifacts
Each run keeps the artifacts it produced so you can inspect exactly what happened after the fact:
- Source freshness tab: when a run checked source freshness, its results are captured per run, so you can see which sources were current at the time and trace a stale-data incident back to the exact run
- Artifact download: download the run's generated artifacts (compiled SQL, manifest, run results) directly from the run detail page for offline inspection or auditing
Health Dashboard
At-a-glance view of all scheduled jobs:
- Which jobs are running now
- Which jobs succeeded or failed recently
- Upcoming scheduled runs
- Average duration and success rate trends over time
Alerting
Scheduled runs integrate with Notifications:
- Get alerted on failure (or even on success, if you want confirmation)
- Set SLA alerts when a job takes longer than expected
- Receive a daily digest of all scheduled run outcomes
Merge Triggers
In addition to cron schedules, jobs can be triggered automatically when code merges to a branch:
- Enable the Merge trigger toggle on any job
- Select the branch to watch (typically your default branch)
- The job runs automatically after each merge, ensuring production is always up to date
- Works with all supported Git providers (GitHub, GitLab, Azure DevOps, Bitbucket)
Multi-Provider Support
Scheduled jobs work seamlessly across all supported Git providers. When a job triggers, the platform clones your project repository from the correct provider using stored credentials:
| Provider | Clone method | Branch resolution |
|---|---|---|
| GitHub | OAuth / Personal Access Token | Automatic default branch detection |
| GitLab | Personal Access Token | Automatic default branch detection |
| Azure DevOps | Personal Access Token | Automatic default branch detection |
| Bitbucket | App password | Automatic default branch detection |
If your project was created before default branch detection was available, the scheduler automatically resolves the correct branch from your provider.
Manual Triggers
Any scheduled job can also be triggered manually:
- Click Run Now to execute outside the normal schedule
- Useful for backfills, reruns after fixes, or ad-hoc refreshes
- Manual runs appear in the same history alongside scheduled runs
Post-Run Actions
Trigger downstream systems automatically when a scheduled job completes:
Power BI Refresh
Refresh Power BI semantic models after your dbt run finishes:
- Select one or more workspace:model pairs to refresh
- Supports multiple workspaces in a single job
- Uses a reusable Integration Credential (service principal) stored centrally on the Integrations page
- Refresh triggers only when the dbt run succeeds
API Endpoint
Call any HTTP endpoint when a job reaches a terminal state:
- Configure a base URL with authentication (Bearer token, API key, or Basic auth)
- Stored as a reusable Integration Credential for use across jobs
- Supports automatic retries with linear backoff on transient failures
- Useful for triggering downstream pipelines, Slack bots, or custom webhooks
Configuration
Add post-run actions in the "When this finishes" section of the schedule wizard. Each action specifies:
- Which integration credential to use
- Which targets to trigger (datasets, endpoints)
- Whether to wait for completion before marking the action as done
Streaming Run Logs
Monitor job execution in real time:
- Logs stream live while the job is running (auto-refreshes every few seconds)
- Full dbt output with syntax highlighting
- Logs persist after completion for debugging and audit
Job Runs Overview
The job detail page includes a visual runs overview chart with a switcher between four views so you can read run health from different angles:
- Build duration: a per-run scatter of how long each run took, to spot slow-downs and outliers
- Success rate: a per-day trend line of the share of runs that succeeded
- Run outcomes: per-day stacked bars breaking runs into succeeded, errored, and skipped
- Runs volume: per-day bars showing how many runs happened
All views share one frame, scale with the page width for readability, and make it easy to detect flaky or degrading jobs at a glance.