dbt Cloud Jobs
A dbt Cloud Job is a configured run of one or more dbt commands that executes on a schedule or on demand. Jobs replace the need for an external scheduler like Airflow or Cron when using dbt Cloud. You define what commands to run, which environment to use, and when to trigger the job.
What a Job Does
A job runs dbt commands against your warehouse: Example production job: Command 1: dbt deps ← install packages Command 2: dbt seed ← load seed CSV files Command 3: dbt build ← run models + tests + snapshots Command 4: dbt source freshness ← check raw data is up to date Runs on: every day at 6:00 AM UTC Environment: production Notifications: Slack #data-alerts on failure
Creating a Job
In dbt Cloud, navigate to Deploy > Jobs > Create Job. Fill in:
Job Name
A descriptive name like "Daily Production Run" or "Hourly Finance Refresh".
Environment
Select the production environment (or whichever environment the job should run against).
Commands
Add the dbt commands to execute in order:
dbt deps dbt build
Schedule
Choose when to run: custom cron expression, hourly, daily, or specific days of the week.
Triggers
Jobs can trigger on a schedule, via API, or after another job completes.
Types of Jobs
Deploy Job
Runs dbt commands in production on a schedule. This is the standard daily or hourly pipeline that keeps your warehouse up to date.
CI Job
Runs automatically when a pull request is opened. dbt Cloud creates a temporary schema, runs the changed models and their tests, then reports results back to GitHub or GitLab. The PR cannot merge if the CI job fails.
PR opened in GitHub
|
v
dbt Cloud CI job triggers automatically
|
v
Runs: dbt build --select state:modified+
(only changed models and their children)
|
v
Results posted to GitHub PR as a status check
|
Pass → PR can be merged
Fail → PR is blocked until issues are fixed
Job Commands Best Practice
Minimal production job: dbt build Full production job with all checks: dbt deps dbt source freshness dbt build dbt run-operation cleanup_old_relations CI job (only test changes): dbt build --select state:modified+ --defer --state ./prod-artifacts
Slim CI with --defer
Running the full project on every pull request takes too long. Slim CI runs only the changed models and defers unchanged models to production:
dbt build --select state:modified+ --defer --state ./prod-artifacts
The --defer flag tells dbt: "for any model not in my selection, read from the production version instead of rebuilding it." This makes CI jobs fast even in large projects.
Job Run History
Every job run appears in the Run History tab with:
- Start time and duration
- Status: Success, Error, Cancelled
- Model-level results (how many passed, failed, skipped)
- Full console output for each command
- Links to the compiled SQL for any failing model
Job Notifications
Configure alerts so the right people know when a job fails:
Notification options: Email: send to specific addresses on success/failure/warning Slack: post to a channel with run summary and link to details Webhook: call a custom URL (for PagerDuty, OpsGenie, etc.) Trigger conditions: On any run completion Only on failure Only on success after a previous failure (recovery alert)
Job Artifacts
After each job run, dbt Cloud stores the run artifacts: manifest.json, run_results.json, and catalog.json. These power:
- The hosted documentation site (updates after every production run)
- Slim CI comparisons (next CI run compares against latest production artifacts)
- Third-party integrations (DataHub, Monte Carlo, etc.)
Job API Trigger
Trigger a job from an external system using the dbt Cloud API:
curl -X POST \
https://cloud.getdbt.com/api/v2/accounts/{account_id}/jobs/{job_id}/run/ \
-H "Authorization: Token {your_api_token}" \
-H "Content-Type: application/json" \
-d '{"cause": "Triggered by Airflow DAG"}'
Use this to trigger dbt runs from Airflow, Prefect, Dagster, or any other orchestration tool after upstream ingestion jobs complete.
