# Weekly dbt Cloud pipeline health and performance report

> Every Monday, get an emailed rundown of your dbt Cloud runs: success rates, the slowest models, and which builds are trending slower.

- Workflow type: agent
- Services: dbt Cloud, Gmail
- Categories: Engineering, Operations
- Published: 2026-07-17

## What it does

- Pulls the last seven days of dbt Cloud job runs and reads how long every model took to build.
- Calculates your overall success and failure rate for the week so you can see pipeline reliability at a glance.
- Surfaces repeated failures and the biggest build-time slowdowns at the top, with a model-by-model table below.
- Emails the whole summary to your data team first thing every Monday morning.

## What you'll need

- A dbt Cloud account with a service token that can view jobs and runs.
- A Gmail account to send the report from.
- The email addresses of the data team who should receive the report.

## Prompt

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.

## How to customize

- Change the send time or day, such as every Monday at 8am or a daily digest instead.
- Swap in the exact recipients on your data team distribution list.
- Adjust what counts as a slowdown, or how many of the slowest models to highlight.

## Example output

Subject: Weekly dbt Cloud health — 2 recurring failures, 3 models slower

⚠️ Needs attention
- fct_orders failed 4 of 7 runs this week (0 failures last week)
- stg_payments was cancelled twice on Wednesday

🐢 Biggest slowdowns vs last week
- dim_customers: 6m10s avg, up 42% from 4m20s
- fct_sessions: 11m05s avg, up 28% from 8m38s

Overall: 84% success (38 of 45 runs) across 6 jobs

Model detail
| Model | Avg build time | vs last week | Runs |
| dim_customers | 6m10s | +42% | 7 |
| fct_sessions | 11m05s | +28% | 7 |
| fct_orders | 2m02s | +3% | 7 |

## FAQ

### Does this report include warehouse or compute costs?

No. It focuses on run timing and reliability from your dbt Cloud runs: success and failure rates, the slowest models, and build-time trends. It does not estimate warehouse spend.

### How does it know a model is getting slower?

It compares each model's build time this week against the previous week and flags the ones that are trending meaningfully slower, so you catch regressions before they become a problem.

### Will it still work if some runs failed or were cancelled?

Yes. It reads every finished run in the window, counts failures and cancellations toward the failure rate, and lists repeated failures at the top so the team can act on them.

### Can I send it on a different schedule?

Yes. Monday at 8am is just the default. You can set any schedule you like, such as a different day and time or a more frequent digest.

### Who receives the report?

Anyone you list as a recipient. Most teams send it to a shared data team email alias or distribution list.

Use this prompt in General Input: https://www.generalinput.com/prompts/weekly-dbt-cloud-pipeline-health-and-performance-report