Alerts & Notifications

OpenMetadata has been providing observability alerts right from the start to notify users of important data lifecycle events: schema modifications, ownership shifts, and tagging updates. Users can define fine-grained alerts and notifications.

Starting from the 1.3 release, Data Observability alerts have been completely revamped, simplifying the process of monitoring data. Users can quickly create alerts for:

• Changes in the Metadata: such as schema changes,
• Data Quality Failures: to filter by Test Suite,
• Pipeline Status Failures: when ingesting runs from your ETL systems, and
• Ingestion Pipeline Monitoring: for OpenMetadata’s ingestion workflows

Depending on your use cases, notifications can be sent to owners, admins, teams, or users, providing a more personalized and informed experience. Teams can configure their dedicated Slack, MS Teams, or Google Chat channels to receive notifications related to their data assets, streamlining communication and collaboration. With the alerts and notifications in OpenMetadata, users can send Announcements over email, Slack, or Teams. Alerts are sent to a user when they are mentioned in a task or an activity feed.

Observability Alerts & Notifications

OpenMetadata provides a unified Event Subscription framework that allows you to configure alerts for two main purposes:

1. Data Observability: Monitoring the health of data systems (e.g., Data Quality failures, Schema Drift, Pipeline failures).
2. System & Governance Notifications: Monitoring metadata changes and collaboration events (e.g., new Glossary terms, Tag updates, Ownership changes).

While these alerts serve different use cases and are accessed from different menus within the platform, the configuration process follows a similar workflow.

Required Permissions

Configuration Workflow

Select your use case below to see the specific configuration steps:

Additional Details for the Configuration of External Destinations

OpenMetadata supports multiple external destinations for delivering alerts outside the platform. Each destination type requires a specific setup process.