Skip to main content

​
Data Observability Alerts

Monitor the health of your data systems by setting up alerts for pipeline failures, data quality issues, and schema changes.
Tip: Use Data Observability Alerts for data health monitoring — test failures, schema changes, pipeline issues, and metric updates on data assets. For platform-wide metadata events, governance actions, or collaboration activity, use System & Governance Notifications instead.

​
Add an Alert

Follow these steps to create and configure a data observability alert in Collate.

​
Step 1: Navigate to the Alerts Page

  1. From the left navigation bar, select Observability > Alerts.
  2. Click Add Alert. Add Alert Button

​
Step 2: Name the Alert and Add Context

  1. Enter a unique, descriptive Name for your alert.
  2. (Optional) Add Description to provide further context and clarity regarding the alert’s intent. Input fields for Alert Name and Description

​
Step 3: Select Sources

Choose one or more operational entities to monitor:
  • Container - Monitors schema changes for the container asset
  • Data Contract - Triggers an alert when a data contract status changes
  • Ingestion Pipeline - Monitors status changes to your Collate ingestion pipelines
  • Pipeline - Monitors updates to pipeline assets that you have ingested
  • Table - Monitors schema changes and table metrics changes
  • Test Case - Triggers an alert for the specific test case selected
  • Test Suite - Triggers an alert once for each completed run of the test suite, based on the summary of its test case results. This is a great way to group alerts and reduce notification fatigue
  • Topic - Monitors schema changes for the topic asset
To watch several sources with one alert, select each one from the Source list. After the first source, the field reads Add another…. For example, select Pipeline and Ingestion Pipeline to hear about failed runs of both in one alert. Source field with Pipeline selected and reading Add another, above the list of sources under Data Assets
Note: Changing the sources clears the filters and triggers you chose. Removing a source also clears the destinations.

​
Step 4: Configure Filters (Optional)

Filters let you refine the scope of the alert to focus only on relevant changes, significantly improving the signal-to-noise ratio. With several sources, Add Filter offers only the filters that every chosen source supports. Narrow down events based on a variety of criteria, including:
  • Entity Specific Name: Filter by the defined specific name of the entity.
  • Owner Name: Filter events based on the designated owner of the asset.
  • Domain: Filter events based on the Data Domain the entity belongs to.
  • Filter By Updater Is Bot: Filter to include or exclude changes made by automated ingestion or system processes.
Use the Include toggle to define the logic for the filter condition:
  • Include (Toggle ON): If the event meets the filter condition, the alert is sent.
  • Exclude (Toggle OFF): If the event meets the filter condition, the alert is silenced (not sent).
Note: If you do not set any filter, the alert will apply to all relevant events over the selected source entity type, which may lead to excessive notifications.
Define Filters Filter Options

​
Step 5: Select Trigger Conditions (Optional)

Define the specific conditions that will trigger the alert:
  • Schema Changes - Alert on added, deleted, or updated columns
  • Test Case Status - Trigger when a test result has a status you select: Success, Failed, Aborted, or Queued. The alert fires on every matching result, not only when the status changes
  • Pipeline Status - Alert when pipeline execution has a status you select: Successful, Failed, Pending, or Skipped
  • Metric Updates - Notify when table metrics are updated
Tip: Select multiple trigger conditions to create comprehensive monitoring coverage.
Select Trigger Conditions With several sources, each trigger applies only to the sources named in brackets after it, for example Get Pipeline Status Updates (Pipeline). Add a trigger for each source you want to hear about. If none of the chosen triggers applies to a source, a warning under Source says so, for example: “Ingestion Pipeline: No chosen trigger applies to this source, so none of its events match.” You can still save the alert, but that source sends no alerts until you add a trigger for it. Pipeline and Ingestion Pipeline selected, a warning for Ingestion Pipeline, and the trigger Get Pipeline Status Updates (Pipeline) with the state Failed

​
Step 6: Select Destination

  1. Set the Connection Timeout (Seconds) (default: 10) and Read Timeout (Seconds) (default: 12) to control how long Collate waits when connecting to external endpoints.
  2. Select Add Destination to add one or more notification targets.
  3. Select from Internal or external notification channels. The Internal options depend on the sources you chose:
    • Internal:
      • Admins - Notify all platform administrators
      • Assignees - Notify users assigned to the asset
      • Followers - Notify users following the asset
      • Mentions - Notify users mentioned on the asset
      • Owners - Notify the owners of the asset
      • Teams or Specific Users - Target specific teams or individual users
    • External — select a Type:
      • Email
      • G Chat
      • Ms Teams
      • Slack
      • Webhook
  4. (Optional) Enable Notify Downstream to also notify the stakeholders of assets downstream of the monitored entity. Notify Downstream works with the internal destinations only. For depth, recipients, and examples, see Notify Downstream.
Select Destination

​
Step 7: Select a Notification Template

The Notification Template controls the wording of the message this alert sends — its subject line and body. The alert fires on exactly the same events regardless of which template is chosen; only the text changes. Select Notification Template Choose one of three options from the Notification Template dropdown:
  • System Default Template — the built-in wording, used when nothing else is selected. Suitable for most alerts and requires no upkeep.
  • A saved template — a template already created in Notification Templates and reusable across alerts. Its name, subject, and body appear below the picker for reference (read-only). Edit it from Notification Templates to update it everywhere it is used.
  • Create Custom Template — wording written here and belonging to this alert alone. Editing it affects no other alert.

​
Writing a Custom Template

Subject and body support Handlebars placeholders, so one template adapts to whatever event fired it. Values are nested under two objects:
  • entity — the asset the event happened to: {{entity.name}}, {{entity.displayName}}, {{entity.fullyQualifiedName}}, {{entity.updatedBy}}
  • event — the event itself: {{event.eventType}}, {{event.entityType}}, {{event.userName}}, {{event.timestamp}}
{{publisherName}} (the alert’s own name) and {{emailingEntity}} are also available at the top level. Three helpers are available for values a plain placeholder cannot produce:
  • {{buildEntityUrl entity}} — a link back to the asset
  • {{formatDate event.timestamp}} — a human-readable timestamp
  • {{camelCaseToTitle name}} — converts a field name into a readable label
Each helper requires an argument; writing one on its own resolves to nothing. Type {{ in either field to browse the full set of available helpers. Example:
Select Validate before saving. It checks Handlebars syntax only — a misspelt or non-existent placeholder passes validation and renders as empty text in the delivered message. For full details on creating and managing templates, including Handlebars placeholders, helpers, and examples, see Notification Templates.

​
Native Pipeline Alert Boundaries

Native pipeline alerts react to status events reported to Collate. They do not evaluate whether an expected event is missing or whether a run took longer than a threshold. The same boundary applies to Automations jobs: their reported failure and partial-success states can trigger native alerts, but missed schedules and duration thresholds require an external check. For an external check on Collate ingestion pipelines and Automations jobs, query GET /api/v1/services/ingestionPipelines/{fqn}/pipelineStatus. Use startTs and endTs to select a time window. The response includes pipelineState, startDate, and endDate for each run. For an ingested pipeline asset, such as an Airflow, Dagster, or Fivetran pipeline, query GET /api/v1/pipelines/{fqn}/status with the same startTs and endTs parameters. The response includes executionStatus, timestamp, endTime, and taskStatus for each run. The timestamp field identifies the run and is not a reliable wall-clock time, so use endTime and the task start and end times to measure duration. A monitoring script can compare these values with the expected schedule or duration threshold before sending a notification. These pages cover alert behavior, webhook delivery, and the API.