Chained dbt Cloud Jobs with Dependencies

Chain several dbt Cloud jobs into a single dependency-aware pipeline so your warehouse builds in the right order every time: staging models first, then marts, then exposures. dbt Cloud schedules each job independently, but it cannot express that marts must wait for staging and exposures must wait for marts across separate jobs. This blueprint closes that gap by running each dbt Cloud job and waiting for it to finish before starting the next, so a failure early in the chain stops the pipeline before stale or partial data reaches downstream consumers.

How it works

The flow takes three inputs (staging_job_id, marts_job_id, exposures_job_id) and runs three sequential io.kestra.plugin.dbt.cloud.TriggerRun tasks:

• run_staging triggers the staging job with wait: true and blocks until it completes.
• run_marts then triggers the marts job, again with wait: true.
• run_exposures triggers the exposures refresh last.

Shared accountId and token are injected once via pluginDefaults so each TriggerRun task stays clean. After the chain succeeds, notify posts to Slack through io.kestra.plugin.slack.notifications.SlackIncomingWebhook. A disabled io.kestra.plugin.core.trigger.Schedule (nightly_pipeline, cron 0 1 * * *) is included so you can run the pipeline automatically once enabled.

What you get

• Strict staging then marts then exposures ordering enforced by wait: true.
• Early-stop behavior: a failed stage halts the chain so downstream models never build on bad data.
• A Slack message confirming the full run finished.
• Per-job results available on outputs.run_staging, outputs.run_marts, and outputs.run_exposures.

Who it's for

• Analytics engineers managing dbt Cloud projects with cross-job dependencies.
• Data platform teams that need reliable, ordered warehouse refreshes.
• Anyone splitting a monolithic dbt Cloud job into stages for better failure isolation.

Why orchestrate this with Kestra

dbt Cloud can schedule individual jobs, but it has no native way to chain separate jobs with hard dependencies and stop on first failure. Kestra adds that orchestration layer: declarative YAML pipelines, event or schedule triggers, retries on transient API errors, and full execution lineage across every stage. You see exactly which job failed and why, instead of discovering broken marts after the fact.

Prerequisites

• A dbt Cloud account with three jobs configured for staging, marts, and exposures.
• A Slack incoming webhook for run notifications.

Secrets

• DBT_CLOUD_ACCOUNT_ID: your dbt Cloud account ID.
• DBT_CLOUD_API_TOKEN: a dbt Cloud API token with permission to trigger runs.
• SLACK_WEBHOOK_URL: a Slack incoming webhook URL.

Quick start

1. Add the three secrets above to your Kestra namespace.
2. Pass the staging_job_id, marts_job_id, and exposures_job_id from your dbt Cloud project.
3. Run the flow manually to confirm the chain executes in order.
4. Enable the nightly_pipeline schedule (or change the cron) to run it automatically.

How to extend

• Add more stages (for example a snapshot or test job) as extra TriggerRun tasks.
• Replace the schedule with a flow trigger so the pipeline starts after an upstream ingestion flow.
• Add error-branch notifications so failures alert a different Slack channel.
• Capture the dbt Cloud run IDs from outputs to link directly to logs in dbt Cloud.

Links

• Kestra dbt plugin docs
• dbt Cloud orchestration with Kestra