Elementary edr monitor alerting

edr monitor is the Elementary CLI command that sends alerts. It reads test results from your warehouse, evaluates which tests failed or warned in the most recent run, and dispatches notifications to your configured destinations.

The quickest way to see it in action:

edr monitor --slack-token $SLACK_TOKEN --slack-channel-name data-alerts

Before configuring any alerting, verify you have test results to alert on. Run edr report --select last_invocation and check that test results appear in the generated HTML. If the report is empty, Elementary’s tables haven’t been populated yet — go back to the setup guide.

edr report vs edr monitor

The two commands serve different purposes and it’s worth being clear about the distinction.

edr report generates a self-contained HTML file for human review. You open it in a browser, explore test history, see anomaly charts, investigate specific failures. It’s designed for scheduled reporting and async consumption — not for automated alerting.

edr monitor is designed for automation. It runs after each dbt build, checks for new failures, and sends notifications. It doesn’t generate a report you browse later; it fires and forgets.

Run edr report when you want to share a snapshot with stakeholders or review yesterday’s run during your morning check-in. Run edr monitor in your CI/CD pipeline or on a schedule after each dbt build. They’re complementary, not alternatives.

Configuring alert metadata

What appears in an alert depends on the metadata you’ve put on your models. Without metadata, alerts are sparse — just the test name and table. With metadata, they include owner mentions, relevant tags, and links to the right channel.

models:
  - name: mrt__finance__revenue
    meta:
      owner: "@jessica.jones"
      subscribers: ["@jessica.jones", "@joe.joseph"]
      description: "Daily revenue aggregation for finance reporting"
      tags: ["critical", "finance"]
      channel: finance-data-alerts
      alert_suppression_interval: 24

A few fields that aren’t obvious from the docs:

The owner field controls who gets mentioned in the alert body. subscribers extends that mention to additional people. If you don’t set these, Elementary sends an alert with no mention — which means it’ll get seen when someone scrolls the channel, not when someone needs to act.

channel routes the alert to a specific Slack channel rather than your default. This is how you keep finance failures in #finance-data-alerts and marketing failures in #marketing-data-alerts, rather than dumping everything into one shared channel that everyone eventually mutes.

alert_suppression_interval controls how long Elementary waits before resending an alert for the same failing test. Set it to 24 and a test that fails at 9am won’t alert again until 9am the next day, even if it keeps failing on every run in between. This is covered in more depth in Elementary alert fatigue reduction.

Path-based defaults

Setting metadata on individual models works fine at small scale. For larger projects, you want defaults that apply to entire directories without having to repeat configuration on every model.

In dbt_project.yml:

models:
  your_project:
    marts:
      finance:
        +meta:
          channel: finance-data-alerts
          alert_suppression_interval: 12
      marketing:
        +meta:
          channel: marketing-data-alerts

Every model under marts/finance/ now routes to #finance-data-alerts with a 12-hour suppression interval, without any per-model YAML. Individual models can still override these defaults if they need different behavior.

Running edr monitor in CI/CD

The typical pattern is to run edr monitor as a step in your pipeline after dbt build or dbt test completes.

# GitHub Actions example
- name: Run dbt build
  run: dbt build

- name: Send Elementary alerts
  run: edr monitor --slack-token $SLACK_TOKEN --slack-channel-name data-alerts
  env:
    SLACK_TOKEN: ${{ secrets.SLACK_TOKEN }}

edr monitor reads from Elementary’s warehouse tables, so it doesn’t re-run tests — it just checks the results that dbt build already wrote. The warehouse tables are the interface between dbt’s execution and Elementary’s alerting.

For more advanced routing — sending different failures to different channels, filtering by tag or owner — see Elementary alert routing with filters.