Weekly dbt Cloud pipeline health and performance report

On a cron schedule every Monday at 8am, email the data team a weekly dbt Cloud pipeline health and performance report. Use dbt Cloud to gather the runs, read each run's per-model timing, compute the key trends, and send a scannable summary with Gmail.

Step 1 — Gather the runs. Use dbt Cloud List Jobs to get the account's jobs, then use List Runs to pull every run whose finish time falls in the past seven days. Also pull the seven-day window before that (days 8 to 14 ago) so you have a prior-week baseline to compare against. dbt Cloud run status codes are 10 = Success, 20 = Error, 30 = Cancelled; treat Error and Cancelled as failures.

Step 2 — Read per-model execution times. For each finished run, use Retrieve Run Artifact to download that run's run_results.json. For every node in the results, read execution_time to see how long each model took to build. Aggregate execution_time per model across the runs in each week (for example, average build time per model this week versus the prior week).

Step 3 — Compute the report. Calculate the overall success and failure rate across all runs in the past seven days. Identify the longest-running models by build time. Flag any models whose build time this week is trending meaningfully slower than the prior week (compare each model's average execution_time between the two windows and call out the biggest regressions). Also identify models or jobs with repeated failures across the week.

Step 4 — Write a scannable summary. Put repeated failures and the biggest runtime regressions at the very top so the team can act immediately. Follow with a short overview line for the overall success and failure rate. Below that, include a short table of model-level detail (model, average build time, change versus last week, run count). Keep it tight and skimmable.

Step 5 — Send it. Use Gmail Send a Message to email the finished report to the data team distribution list, with a subject line that leads with the headline (for example the number of recurring failures and models trending slower).

Keep the report focused on run timing and reliability. run_results.json exposes per-node execution time, not warehouse or compute spend, so do not include or estimate warehouse cost figures. Report only what the run data actually contains.