Job Alerting Moved to Job Monitors

Monte Carlo has moved job alerting from settings spread across audiences, integrations and dbt projects to job monitors. Monte Carlo moved each account itself. You don't need to do anything: your job failures alert the same audiences as before, and you manage them from the Monitors page.

This page covers what the move changed, how your previous settings became job monitors, and how to review the result with See what changed.

👍
Same alerts, same audiences. Before moving an account, Monte Carlo checked that every job failure that alerted was still covered, and that no failure gained or lost an audience.

What changed

flowchart LR
    subgraph before ["Before: job alert settings"]
        T["Per-job alert toggles<br>on integrations"]
        D["Alert types<br>on dbt projects"]
        J["Job notifications<br>on audiences"]
    end
    subgraph after ["After: job monitors"]
        M["Job monitors<br>on the Monitors page"]
    end
    T --> M
    D --> M
    J --> M

Before the move, three separate settings decided whether a job failure alerted and who heard about it. Now job monitors decide both.

Before	Where it was	Now
Per-job alert toggles, such as Generates alerts	Settings → Integrations → your integration → Configure DAGs / Configure pipelines / Configure jobs	The jobs a monitor covers, under Choose jobs
dbt alert types (model, test, snapshot and seed failures, and test warnings)	Settings → Integrations → your dbt connection → Send alerts for	A monitor's Alert conditions
Per-job dbt alert checkboxes	Settings → Integrations → your dbt connection, expanding a project's jobs	The jobs a monitor covers, under Choose jobs
Job notifications on an audience	Settings → Notifications → your audience → Job notifications tab, and the Job notifications column on the audiences list	A monitor's Send alerts to
Enable monitoring on a job	The job's Alerts tab	Any job monitor that covers the job
Not monitored label	The Alerts column on the Jobs page	The Monitors column on the Jobs page

Screens that are no longer shown

These screens and controls are no longer shown:

Job notifications tab on audiences, and the Job notifications column on the audiences list. Links to add or edit a job notification redirect to the audience.
Configure DAGs (Airflow), Configure pipelines (Azure Data Factory) and Configure jobs (Databricks and other integrations) on integration pages: Airflow, Azure Data Factory, custom ETL connectors, Databricks, GCP Dataform, MuleSoft, Power BI Dataflows, Salesforce Data Cloud and Snowflake.
Send alerts for on dbt connections, including the per-project alert types and per-job alert checkboxes. The column is now Job tags, and Propagate model tags to job assets stays. Repeated-failure grouping settings on the dbt connection also stay.
Enable monitoring on a job's Alerts tab.
Not monitored in the Jobs page Alerts column.

What stays the same

Audiences and their recipients. Monitors created by the move notify the same audiences.
Your integrations and job data. Jobs, runs, lineage and the Jobs page are unchanged.
Your previous settings are kept, not deleted. They are stored as they were but no longer take effect.

How your settings became job monitors

Monte Carlo read your per-job toggles, dbt project alert types and audience job notifications, and created the smallest set of job monitors that reproduces them.

Your previous settings	Resulting monitor
Jobs routed to an audience through Job notifications	One monitor per integration for each set of audiences that received the same jobs. It lists those jobs one by one.
Jobs with alerts on but no audience routing them	One monitor per integration with no audience, titled `Unrouted — <integration>`. These alerts notified nobody before, and still don't.
dbt projects on a connection with the same alert types	One monitor per group of projects, covering those projects, with the alert types as its alert conditions. Jobs you had muted are excluded.
A dbt job notification filtered to certain tables	Its own monitor, with the tables as Limit to tables.

Monitors created by the move have:

A title from their audiences and integration, such as Data Eng, Platform — airflow-prod. Past three audiences, the title ends , +N more.
A note recording where they came from, such as Migrated by Monte Carlo from the job notifications of audience "Data Eng" on 2026-10-20 (UTC).
No domain. Assign domains if you use them.
The default alert grouping, Group failures from the same job for 12 hours.

They are ordinary job monitors. You can edit, pause or delete them, or replace them with your own.

Monitors as code

Monitors created by the move are in the monitors-as-code namespace job-alerting-migration. Don't apply your own monitors-as-code projects to this namespace. See Monitors as code.

See what changed

Monte Carlo shows where job alerting went.

Where	What you see
Monitors page	A notice, Your job alerting now runs from job monitors, with the number of monitors created and the screens your account used that are no longer shown.
Audiences, job pages and integration pages	A callout: Job alerting now runs from job monitors.
Sidebar	Job alerting moved to job monitors, with View job monitors.
A Details tab of a monitor created by the move	A line such as Created by the job alerting migration on `<date>` from Data Eng's job notifications.

Each of these links to See what changed.

The See what changed summary

See what changed opens What changed in job alerting, a summary of how your account moved. It shows three totals: Monitors created, Jobs alerting nobody and Settings changed.

Monitors created lists each monitor created by the move with its integration, its audiences, and where it came from, for example From Data Eng's job notifications.

Monitors outside your domains are counted but not listed. Monitors created by the move have no domain, so ask an admin to assign them to yours.
Monitors deleted since the move are counted.

Worth a look lists settings worth reviewing:

Section	What it means	What to do
Jobs that alerted nobody	Jobs with alerts on but no audience. Their monitors have no audience, so they still notify nobody. Each row shows how many jobs it covers and how many failed in the 90 days before the move.	Add an audience to the monitor, or delete it.
dbt conditions no longer alerting	Your job notifications named these dbt conditions, but the project had them turned off, so they never alerted. No monitor covers them.	Add the condition to a monitor if you want these alerts.
Settings that work differently	Settings that job monitors handle differently. See below.	Review the affected monitors.

To open the summary again later, choose See what changed on the Monitors page notice or on a monitor created by the move.

Settings that carried over differently

A few settings have no exact equivalent in job monitors:

Custom messages are no longer sent with job alerts. Add the text to the monitor's Notes instead.
Table filters became fixed table lists. A dbt job notification that filtered tables by pattern now lists the tables that matched when your account moved. Tables added later aren't covered.
Table exclusions became fixed table lists. Tables added later don't alert these audiences.
Jobs are listed one by one on non-dbt monitors. The per-job toggles applied to one job at a time, so Airflow, Databricks and other non-dbt monitors created by the move list their jobs individually. New jobs aren't covered until you add them. To cover new jobs automatically, change the monitor to All jobs in the integration, or use a tag rule.

Using the API

The GraphQL mutations that changed the previous job alert settings return the error JOB_ALERT_SETTINGS_MIGRATED:

This account uses job monitors, so job alert settings cannot be changed. Job monitors decide which job failures alert, so these settings have no effect. Use job monitors to change job alerting.

Rejected mutations
`setJobGeneratesIncidents`, `setJobGeneratesAlerts`
`setEtlJobGeneratesIncidents`, `setEtlJobGeneratesAlerts`, `bulkSetEtlJobGeneratesAlerts`
`setEtlJobGeneratesAlertsV3`, `bulkSetEtlJobGeneratesAlertsV3`
`setProjectGenerateAlertsFor`, `setProjectGenerateIncidentsFor`
`createOrUpdateAudienceRoutingRule`, for rules on job alert types

deleteAudienceRoutingRule, setProjectPropagateJobTags and routing rules for other alert types still work. Update any scripts that use the rejected mutations to use job monitors, through the UI or monitors as code.

After the move

Open See what changed and review Worth a look.
Give unrouted monitors an audience, or delete them if you don't want those alerts.
Assign domains to monitors created by the move if your account uses domains.
Replace picked jobs with rules where you want new jobs covered automatically.
Check webhooks for webhook-based integrations, so alerts aren't delayed. See Prerequisites.

FAQs

Do I need to do anything?

No. Monte Carlo moved your account and checked that your alerts reach the same audiences. Reviewing See what changed is recommended.

Will I get more or fewer alerts?

Every failure that alerted before still alerts, to the same audiences. No failure starts alerting that didn't before. The exceptions are the settings listed under Settings that carried over differently.

Can I edit or delete monitors created by the move?

Yes. They are ordinary job monitors. Deleting one stops the alerts it sent.

Where did my job notification settings go?

They are stored as they were, but no longer take effect. Job monitors now decide which job failures alert.

Why can't I see some monitors created by the move?

Monitors created by the move have no domain. If your access is limited to certain domains, See what changed counts these monitors but doesn't list them. Ask an admin to assign them to your domain.

How do I alert on a new job?

Create a job monitor, or add the job to an existing one. See Job monitors.

Something looks wrong after the move. Who do I contact?

Contact Monte Carlo support with the monitor or job involved.