Notifications & Alerts
Stay on top of your data pipeline without watching it. When a scheduled run finishes, dbdeux tells the people who need to know, in the places they already work, and records every delivery so you can prove what was sent.
Never Miss a Failure
Data pipelines run around the clock. You should not have to. Every scheduled job can notify on the outcomes that matter:
- Failures: a run that failed, timed out, or was aborted
- Successes: positive confirmation that a run completed cleanly, for the jobs where silence is not reassuring enough
- Test failures: a run whose dbt tests failed or errored, even when the run itself reported success. This catches the case that quietly bites teams: the build worked, the data did not
When test results are available, the message is enriched with a pass, fail, warn, error, and skipped summary plus the first few failing test names, so the alert itself often tells you enough to act.
Delivery Channels
| Channel | How it works |
|---|---|
| Slack | Connect the dbdeux Slack app once and pick channels from a list. The summary lands in the channel with the details in a thread, so a busy channel stays readable. A pasted incoming webhook still works as a fallback |
| Microsoft Teams | A card posted to a Teams channel through its Workflow webhook |
| A plain, readable summary sent to the recipients you list | |
| PagerDuty | Incidents that open on failure and resolve on recovery. Reference a saved PagerDuty credential from Integrations, or paste a routing key |
| Webhook | A signed message to your own HTTPS address, so an internal tool or ticketing system can react to the event. dbdeux generates the signing secret for you, or you paste one the receiving system already knows |
| In-app | The bell in the app header. Members of the organization see it there, with an unread count and one-click mark as read; alerts addressed to one person show up for that person only |
| API endpoint | A POST with the run context to any authenticated endpoint, configured as a post-run action so you can drive downstream systems |
Channels are independent. A slow or broken Slack endpoint never stops the emails from going out, and a failing channel never delays the run itself being reported as finished.
One Click from the Alert to the Log
Every Slack message and email carries a View run in dbdeux button. It opens the Jobs page with the right workspace and job already selected and the log for that exact run open in front of you, so the path from a 3 a.m. alert to the failing statement is a single click. The run is looked up directly if it is older than the runs currently loaded, so a link from last week resolves just as well as one from a minute ago, and once you have landed the job stays in the address bar so a refresh returns to the same job without reopening the log. Run pages are shareable for the same reason: paste the address into a ticket and a teammate lands on the same run.
The link holds even when you are signed out. Open it from your phone at 3 a.m., sign in, and you land on that run, not on a home page you then have to navigate away from. The same is true of every shareable address in dbdeux, whether it points at a run, a catalog object, or a Semantic Layer definition. A run that has aged into the read-only archive still opens from the same link, with its log intact.
PagerDuty and Auto-Resolve
For on-call alerting, a failure triggers an incident and a clean success resolves it automatically against a stable per-job key. Your on-call does not wake up to an incident that fixed itself an hour ago, and nobody has to remember to close it by hand.
Set this up in the Notify step of the schedule wizard, or edit it on an existing job. Referencing a saved PagerDuty credential is preferable to pasting a routing key on each job: rotate the key once in Integrations and every job that references it follows.
Configuring Notifications
Notifications are configured per scheduled job in the Notify step of the schedule wizard, and can be edited any time from the job's detail page:
- Pick a Slack channel (or paste an incoming webhook), or leave it blank to inherit the organization default
- List email recipients, or leave the list empty to inherit the organization default
- Optionally select a PagerDuty credential, or paste a routing key
- Choose the gates: notify on failure (on by default), on success, on test failure, and on test warning
The two test gates are deliberately separate. A dbt test failed covers tests that failed or errored, even when the run itself finished. A dbt test warned covers tests you marked severity: warn: they tripped, the run kept going, and you still want to know. Turn the second one on for source freshness checks and soft data quality rules, and your team hears about a slowly staling feed without anyone having to fail the build to get attention.
The wizard shows a one-line summary of exactly who will be told and on which outcomes, so a job never ships with notification settings you did not intend.
Organization Defaults
An organization owner or admin can set a default Slack channel and default email recipients on the Notifications tab of organization settings.
- Jobs that leave both fields blank inherit the defaults, so a new job is never silently unmonitored
- The wizard shows an inheritance banner naming what will be used, rather than leaving you to guess
- Setting either field on the job overrides the default for that job only
This is the practical difference from tools where alerting is per job only: onboarding a new job does not depend on somebody remembering to wire up alerts.
The Notifications Hub
Per-job alerts tell you a run failed. They do not tell you that the same job has now failed three nights running, that a schedule quietly never started, or that a run is taking twice as long as usual. Those are the alerts that catch problems before a stakeholder does, and they live on the organization's Notifications tab, laid out as a short guided path: connect Slack, set your defaults, then add routing rules and a daily digest when you want more.
Events Worth Waking Up For
A routing rule starts from an event. They come in three groups:
| Group | Events | What it tells you |
|---|---|---|
| Job health | Still failing, Recovered, Missed schedule, Slow run, Post-run action failed, Source freshness failed | The patterns behind a single failed run: a job that has failed a number of times in a row (you pick how many), the first success after those failures so the people who saw the alert know it is over, a scheduled run that did not start within its grace period, a run that ran longer than a fixed number of minutes or a multiple of its usual duration, a Power BI refresh or downstream trigger that did not go through, and a source past its freshness threshold. These can be limited to one environment, for example production only |
| Workspace and catalog | Maintenance mode on, Maintenance mode off, Change request status | Someone paused a workspace's schedules (or the pause ended), or an owner accepted, declined, or completed a catalog change request |
| Account and plan | Snowflake password deadline, Sign in to Snowflake again, Plan limit near, Plan limit reached, AI budget warning, AI budget blocked | A connection still on a deprecated password as its switch-by date nears, a developer whose Snowflake sign-in has expired (sent to that person only), usage at 80 percent of a plan limit or a create that was refused because of one, and the AI budget at its warning line or paused for the rest of the month |
Recovered is the one teams underrate. Without it, a failure alert at 2 a.m. is still an open question at 9 a.m. With it, the same channel that carried the failure carries the all-clear, and nobody has to go and check.
Three Steps to a Rule
Creating a rule is three short screens: what to alert on (the event and its setting, such as the number of consecutive failures), its scope and timing (all environments or one, a name for the rules list, cooldown, quiet hours), and where it goes. Every destination you turn on receives the alert, so one rule can page on-call, post to the team channel, and light the bell at the same time. Tick several events on the first screen and dbdeux creates one rule per event with the same scope, timing, and destinations, so setting up "still failing, missed schedule, and slow run, all to #data-alerts" is one pass rather than three. Rules can be paused without being deleted, and only owners and admins can change them.
Routing rules are one of the counted allowances on Plan & Limits. The rules card shows how many you are using against your plan, turns amber as you approach the limit and red when you reach it, and explains what to do next instead of failing quietly. Pausing a rule keeps its slot; deleting one frees it.
Two controls keep a noisy night from becoming a noisy channel:
- Cooldown: after a rule delivers an event for a job, repeats of the same event are recorded as skipped until the cooldown passes. A job that fails every ten minutes produces one alert an hour, not six
- Quiet hours: a window, which may cross midnight, during which the rule records events as skipped instead of delivering them. PagerDuty resolves always go through, so an incident never stays open because it happened to clear at 3 a.m.
In both cases the skip is written to the delivery history with its reason. Nothing is silently dropped, which is the difference between "quiet" and "blind".
One Digest a Day
On top of immediate alerts, the Daily digest sends one summary a day of the events you pick (or every routable event), at the time and in the time zone you choose, to a Slack channel, a Teams channel, email recipients, or all three. It respects its own quiet hours, shows when the last digest went out and what it covered, and has a Send now button for the morning you want it early. A digest with nothing to report is recorded as such rather than sent empty.
Notify Me on Slack
Below the organization settings sits a personal section, Notify me on Slack, that nobody else sees or changes. Here you ask the dbdeux Slack app to send you a direct message for the events that are about you:
| Event | You hear about it when |
|---|---|
| My job failed | A scheduled job you created, or a run you started, failed or timed out |
| Request or question for me | A change request or question was addressed to you as an owner, or your own request got a reply or a new status |
| Object I own changed | A model you own changed in a new catalog version, or a Slimmer CI run touching it failed |
| Sign in to Snowflake again | Your own Snowflake sign-in needs renewing |
The card shows how you are matched to a Slack account: by your dbdeux sign-in email, which needs nothing from you if the two addresses are the same, or by a Slack member id you paste when they differ. Send test DM confirms the match before you rely on it, and your choices are saved even before the organization has connected Slack, so the messages simply start arriving once it does.
Delivery History, Organization-Wide
Every message the organization sent, skipped, or failed to send is listed on the same tab, newest first, with filters for status, event, job, environment, channel, and date range. A skipped entry names why: cooldown, quiet hours, no channel configured, or the gate was off. Combined with the per-job Notifications tab below, "why did nobody get paged?" is answerable at the organization level too, in the time it takes to set one filter.
How This Compares
| Per-job alerts only | Alerting bolted on outside the tool | dbdeux Notifications hub | |
|---|---|---|---|
| Consecutive failures, missed schedules, slow runs | Not detectable from one run | Requires exporting run data and writing rules elsewhere | Built-in events with your thresholds |
| Recovery notice | Rarely | Depends on the external tool | Recovered event to the same destinations |
| Noise control | None | Varies | Cooldown and quiet hours, every skip recorded |
| Where alerts go | One channel per job | One destination per rule | Slack, Teams, PagerDuty, email, signed webhook, and in-app, all from one rule |
| Proof of delivery | Per job, if at all | Somewhere else | One organization-wide history with filters |
Delivery History You Can Audit
Beyond the organization-wide view, every job and every run has a Notifications tab listing each delivery attempt, with the channel, the outcome, and the response detail when a channel rejected the message.
Crucially, skipped attempts are recorded too, with the reason: no webhook configured, no recipients listed, or the channel gated off for that outcome. The history is never silently empty, so "why did nobody get paged?" is a question you can answer in seconds instead of an argument.