What you will be able to do
- Choose which run outcomes (Succeeds, Warns, Fails, Is canceled) should send an alert, and predict when a run labelled "success" still sends a warn notification
- Configure email notifications per environment and per job from Notification settings
- Send job emails to external addresses such as a Microsoft Teams channel or a PagerDuty email integration
- Set up model notifications so that group owners get emails about their own models and tests
Key concept
Job notification subscription — In dbt you subscribe a recipient to outcomes, not to whole jobs. For each job in an environment you choose which run statuses should send that recipient a message.
1.Run outcomes that trigger an alert
A scheduled job that fails at 3 a.m. helps nobody if the first person to notice is a stakeholder at 9. Job notifications close that gap: when a job run ends, dbt platform tells the people who asked to know. Alerts can go out by email, through user-linked or account-level Slack, or through Microsoft Teams. Email reaches the furthest of these, because any address can receive it, including addresses that belong to other tools.
Every subscription is built from four outcomes. You pick any combination of them for each job, and dbt sends a message only when a run ends in one of the outcomes you picked. If you subscribe only to Fails, a cancelled run sends you nothing. Each outcome is a separate choice, and a broader one does not include the others.
| Option | Sends a notification when |
|---|---|
| Succeeds | A job run completed successfully with no warnings or errors |
| Warns | Data tests or source freshness checks logged warning-level lines, even if the run itself shows success |
| Fails | A job run failed to complete |
| Is canceled | A job run is canceled, including by the inactivity-timeout cleanup |
Warns is the option people most often misread. It responds to warning-level log lines from data test and source freshness steps, not to the job's overall status. So one run can do two things at once: it shows "success" in the interface, and it still alerts everyone subscribed to Warns. A team that subscribes only to Fails will never hear about a test that is drifting towards failure. If you want those early signals, subscribe to Warns.
How you run source freshness decides whether a stale source stops the job. The Run source freshness checkbox in Execution Settings runs dbt source freshness as the first step, and a failure there won't break subsequent steps, so the rest of the run carries on. If you add dbt source freshness as an ordinary run step instead, stale data makes that step fail and the later steps don't run. dbt then sends email notifications based on that step's end state. Choose the run step when stale data should stop the job and trigger an alert. Choose the checkbox when the models should build anyway.
Checkpoint 1 of 8· Check yourself
A production job has dbt source freshness as its first run step, and an upstream source has stopped loading. An analyst is subscribed to Fails for the job. What happens?
Added as a run step, source freshness fails when the data is out of date, which stops the steps after it. Notifications follow the end state of that step.
“dbt will trigger email notifications (if configured) based on the end state of this step.”Source: docs.getdbt.com
Checkpoint 2 of 8· Exam question
A dbt Cloud account admin needs job-failure alerts routed to the team's PagerDuty on-call rotation, without requiring PagerDuty staff to hold dbt Cloud logins. Which configuration meets this requirement?
Correct answer: A — Add PagerDuty's inbound integration email address as an external email recipient in job notification settings, then enable the Fails trigger for that environment.
- A. External email recipients let an admin route job notifications to addresses outside the dbt account, including a PagerDuty integration inbox, and pairing that with the Fails trigger notifies the rotation automatically whenever the job fails without giving PagerDuty a dbt Cloud login.
- B. Webhooks post a JSON payload to an HTTPS endpoint URL that the receiving system parses, not to an email address, so pointing the target field at an inbox format like this will not deliver an alert.
- C. PagerDuty's dbt integration ingests alerts through email, not through Microsoft Teams adaptive cards, so building this routing through Teams notifications does not reach the on-call rotation.
- D. IT license users can be added as notification recipients but cannot configure notification settings themselves, so granting this license does not let the on-call engineer set up their own alerting.
2.Configuring email alerts for an environment's jobs
Three kinds of user can configure email notifications: developer users, account admins, and anyone holding the Notification Manager permission set. The Notification Manager set comes with [permission sets](lesson:5.2). A developer user can subscribe only themselves. By default, alerts go to the email address on the user's profile page.
The settings are not on the job itself. Select your profile icon, then Notification settings, which opens the Email notifications page. Choose an Environment from the dropdown, click Edit, tick the statuses you want for each job in that environment, and click Save. The result is a grid of environment, then job, then statuses.
Consider a production environment with a nightly build job and a separate job that only checks freshness. You might subscribe to Fails and Is canceled for the nightly build, and to Warns for the freshness job. A staging environment does not inherit any of this. To cover it, choose that Environment from the dropdown and edit its jobs separately. Turning everything off is a single action: Unsubscribe from all email notifications on the same page.
Checkpoint 3 of 8· Put it in order
Put the steps for subscribing to email alerts on a job in order.
- 1.Choose the run statuses for each job
- 2.Click Edit
- 3.Select the Environment for the jobs from the dropdown
- 4.Select your profile icon and click Notification settings
- 5.Click Save
Statuses are set per job, and you can only see a job's statuses after choosing its environment and switching to Edit. Nothing takes effect until you Save.
“Click Edit, select the job statuses you want. Then click Save to save.”Source: docs.getdbt.com
Checkpoint 4 of 8· Exam question
A production job runs nightly and feeds a dashboard used by executives. The data platform team wants email alerts only when something needs human attention, not on routine successful completion. Which trigger statuses should be selected for this job's email notification?(Select 3)
Correct answers: B, C, D — Warns - notify when data tests or source freshness checks produce warning-level results during an otherwise completing run.; Fails - notify when the job run fails to complete due to a model error, test failure, or connection issue.; Is canceled - notify when a run is manually stopped or terminated before finishing, such as by a user or timeout.
- A. This notifies on every routine successful run, which is exactly the noise the team wants to avoid since a normal night's execution needs no human action.
- B. Selecting this surfaces test or freshness problems that complete without a hard failure, which is precisely the kind of borderline result an executive dashboard team needs a human to review.
- C. Selecting this ensures the team is alerted the moment the job cannot complete, which always requires investigation before the dashboard can be trusted.
- D. Selecting this catches runs stopped early by a person or a timeout, which also needs a human to determine whether the job should be rerun.
Sources1
3.Sending job emails to external addresses and other tools
Only an account admin can send notifications to an address other than their own. On the Notification settings page, the Notification email dropdown lists Internal Users with access to the account and any External Emails that have been added. To add an external email, click Add external email at the bottom of the dropdown, enter the address, and click Add user. The new address then appears in the dropdown, and each recipient gets its own set of subscriptions: select the address, Edit its job notification settings, and Save.
External addresses are what let email reach other tools. A Microsoft Teams channel has its own email address. If the native Teams integration isn't available, add the channel's address as an external email and every alert lands in the channel. A PagerDuty email integration works the same way, so a production failure can open an incident instead of sitting in someone's inbox.
These recipients outlive the people who set them up. External emails and their settings persist until someone edits or removes them, even after the admin who added them leaves the account. That is useful for an on-call alias that must not break during staff changes. It also means a forgotten external address keeps receiving production alerts until an admin removes it.
Checkpoint 5 of 8· Check yourself
An on-call team must be alerted about every cancelled production run, including runs cancelled after 10 minutes of inactivity. Which setup does that reliably?
Slack may miss cancellations made by the inactivity-timeout cleanup. Email notifications and webhooks still report them, and a PagerDuty email integration can be added as an external email.
“To receive notifications for these cancellations, use email notifications or webhooks.”Source: docs.getdbt.com
Checkpoint 6 of 8· Exam question
Which user is able to configure job notifications for other teammates' recipients, such as changing which environment a colleague's alerts apply to, rather than only their own personal notification email?
Correct answer: B — An Account Admin, who can open any teammate's notification profile and edit it on their behalf.
- A. A Developer user's notification permissions are limited to their own personal email alerts and do not extend to editing another teammate's channel or environment selections.
- B. Account Admin is the role with broad enough permissions to open a colleague's notification profile in Notification settings and change its channel, environment, or trigger statuses directly.
- C. An IT license grants the ability to be added as a recipient of notifications, such as through an external email, but it does not grant the ability to configure anyone's alerting.
- D. A Job Admin's permission set covers monitoring and rerunning jobs, not editing another user's personal notification recipient or channel configuration.
Sources1
4.Model notifications for group owners
Job notifications report on a whole run to whoever subscribed in the UI. Model notifications report on individual models and tests to the people who own them, and that ownership is declared in project code. If the finance team's sales model fails, the finance owner hears about it directly, without anyone first reading a job-level alert and working out whose problem it is. Owners can subscribe to Success and Fails for models, and to Warning, Success and Fails for tests.
Ownership comes from groups. Define groups in any .yml file in the models directory, and give each group an owner with a name and an email. The email can be a single address or a list of addresses. If you want to keep extra metadata such as a Slack channel, put it under config.meta, not in the owner block.
groups:
- name: finance
owner:
# Email is required to receive model-level notifications, additional properties are also allowed.
name: "Finance team"
email: finance@dbtlabs.com
- name: marketing
owner:
name: "Marketing team"
email: marketing@dbtlabs.com
config:
meta:
slack: '#marketing-team'Next, attach groups to models like any other config. You can set it per model in a properties file. You can also use +group in dbt_project.yml to cover a whole subdirectory at once, for example sending every staging model to data engineering. Attaching a group to a model also covers its tests. To keep the volume manageable, each owner gets one email per job run, listing every model or test that matched the statuses they subscribed to.
Checkpoint 7 of 8· Fill the gap
Which config key attaches the sales model to the finance group, so that the finance owner receives its notifications?
models:
- name: sales
description: "Sales data model"
config:
? : financeModels are attached to groups with the group config. The owner and email live on the group definition, not on the model.
YAML alone does not turn the feature on. A dbt administrator has to open Notification settings, go to Email notifications, and enable Enable group/owner notifications on models under the Model notifications section, choosing the statuses there. The deployment environment must also be on a release track, not a legacy dbt v1 version. If either is missing, the groups file does nothing, and nobody gets an email.
Checkpoint 8 of 8· Check yourself
A team has added groups with owner emails and attached them to their models, but no owner receives model notifications from production runs. Which cause fits?
Model notifications need an administrator to enable the account setting and a deployment environment on a release track. A single email string is valid, and tests are covered through their model's group.
“Your deployment environment(s) must be on a release track instead of a legacy dbt v1 version.”Source: docs.getdbt.com
Sources3
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.A run that shows "success" in the UI cannot trigger a Warns notification.Why is that wrong?
Warns is triggered by warning-level log lines from data test or source freshness steps, not by the job's overall run status.
Covered in Run outcomes that trigger an alert
2.Slack reliably reports every cancelled run, so email is not needed for cancellations.Why is that wrong?
Slack may not show runs cancelled by the 10-minute inactivity-timeout cleanup. Email notifications or webhooks still report them.
Covered in Sending job emails to external addresses and other tools
3.Removing the admin who added an external email also removes that email's notifications.Why is that wrong?
External emails and their settings persist until someone edits or removes them, even after the admin who added them leaves the account.
Covered in Sending job emails to external addresses and other tools
4.Adding group owners with emails in YAML is enough to start model notifications.Why is that wrong?
An administrator must also enable the account setting for group/owner notifications on models, and the environment must be on a release track.
Covered in Model notifications for group owners
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“A job run encountered warnings from data tests or source freshness checks.”
↩︎ Run outcomes that trigger an alert“dbt platform currently supports the following notification channels:”
↩︎ Run outcomes that trigger an alert“You must be a developer user, account admin, or have the Notification Manager permission set to configure email notifications in dbt.”
↩︎ Configuring email alerts for an environment's jobs“As a developer user, you can set up email notifications for yourself.”
↩︎ Configuring email alerts for an environment's jobs“To set up alerts on jobs from a different environment, select another Environment from the dropdown”
↩︎ Configuring email alerts for an environment's jobs“On the Email notifications page, click Unsubscribe from all email notifications.”
↩︎ Configuring email alerts for an environment's jobs“Select another address from the list. The list includes Internal Users with access to the account and External Emails that have been added.”
↩︎ Sending job emails to external addresses and other tools“also for third-party integrations like channels in Microsoft Teams and PagerDuty email integration”
↩︎ Sending job emails to external addresses and other tools“which cancels runs that have been inactive for 10 minutes”
↩︎ Sending job emails to external addresses and other tools“Choose one or more of the run statuses for each job you want to receive notifications about.”
↩︎ Key concept“can still trigger a warn notification if test or freshness steps logged warnings”
↩︎ Exam trap 1“To receive notifications for these cancellations, use email notifications or webhooks.”
↩︎ Exam trap 2“External emails and their notification settings persist until edited or removed even if you remove the admin who added them from the account.”
↩︎ Exam trap 3“can still trigger a warn notification if test or freshness steps logged warnings”
↩︎ Prediction“Click Edit, select the job statuses you want. Then click Save to save.”
↩︎ Checkpoint“To receive notifications for these cancellations, use email notifications or webhooks.”
↩︎ Checkpoint - 2.https://docs.getdbt.com/docs/deploy/source-freshnessOfficial docs
“dbt will trigger email notifications (if configured) based on the end state of this step.”
↩︎ Run outcomes that trigger an alert“will run dbt source freshness as the first step in your job and won't break subsequent steps if it fails.”
↩︎ Run outcomes that trigger an alert - 3.
“Set up dbt to notify model owners through email about issues in your deployment environments.”
↩︎ Model notifications for group owners“The email field supports a single email address as a string or a list of multiple email addresses.”
↩︎ Model notifications for group owners“Attaching a group to a model also encompasses its tests”
↩︎ Model notifications for group owners“The email includes a consolidated list of all models or tests that match the statuses the user subscribed to”
↩︎ Model notifications for group owners“enable the setting Enable group/owner notifications on models under the Model notifications section.”
↩︎ Exam trap 4“Your deployment environment(s) must be on a release track instead of a legacy dbt v1 version.”
↩︎ Checkpoint