In dbt Cloud, now called dbt platform, a deploy job runs a list of dbt commands in a deployment environment, on a schedule or after another job. It builds production from the code on the environment’s Git branch, so the schedule is the only thing that decides when production changes.
Copy and paste
Create the job. On the page of your production environment, click Create job > Deploy job, then fill in:
- Job name:
Daily build - Commands:
dbt build - Run source freshness: on, to check the sources first
- Triggers > Run on schedule: on, with one of the timing options below
Cron schedules for common cases (all in UTC):
| Runs | Cron |
|---|---|
| Every day at 05:00 UTC | 0 5 * * * |
| Every hour, on the hour | 0 * * * * |
| Monday to Friday at 06:30 UTC | 30 6 * * 1-5 |
| The first Monday of the month at 04:00 UTC | 0 4 * * MON#1 |
| The last day of the month at 22:00 UTC | 0 22 L * * |
The three timing options
- Intervals run the job every N hours, counted from midnight UTC: every 2 hours means 00:00, 02:00, 04:00 and so on.
- Specific hours take a list of hours in UTC, for example
0,12,23for midnight, noon and 23:00. - Cron schedule takes any cron expression, including
Lfor the last day of the month andMON#1for the first Monday. See the cron cheat sheet for the syntax.
With intervals and specific hours you can also pick the days of the week; by default the job runs every day.
Always UTC
dbt runs every schedule in UTC and does not adjust for your timezone or for daylight saving time. A job
at 0 5 * * * runs at 07:00 in Rome in summer and at 06:00 in winter. If the job must run at the same
local time all year, either accept the shift, change the cron twice a year, or start the job from an
orchestrator that handles timezones, such as Airflow; see
how to trigger a dbt Cloud job from the API.
Run after another job
Run when another job finishes starts the job when an upstream deploy job completes, with the run statuses you choose. A typical chain is an ingestion check, then the daily build, then a job that refreshes extracts. It needs a Starter or Enterprise plan.
Things to know
- One command per line. The commands run in order and form a chain: if one step fails, the job ends with an error. A failed source freshness check does not stop the job if later steps pass.
- Minimum frequency. On the Developer plan jobs cannot run more often than every 10 minutes.
- Avoid
state:modified+in scheduled jobs. It selects changes in code, not in data. A nightly job with that selector builds nothing when nobody changed the code; keep it for CI jobs. - Advanced settings. Each job can override environment variables, the target name, the timeout and the number of threads (4 by default).
Based on the dbt platform documentation (October 2026); not run against a live dbt account.
