​

Alert Behavior Reference

This page describes how alerts behave once you create them. It covers the available sources, triggers, and filters. It also explains when an alert fires and which kind of alert covers which kind of event. Use it when you design an integration, such as a webhook receiver or a ticketing sync. It tells you what Collate sends and when. For the step-by-step UI procedures, see Data Observability Alerts and System & Governance Notifications. For what a webhook receives, see Webhook Payloads and Delivery.

​

Alert Building Blocks

Every alert is built from the same parts:

• Source: the type of asset or event stream the alert watches, such as Table or Test Case. An alert has exactly one source.
• Trigger: the specific kind of change that should fire the alert, such as a test case status update. Only Observability alerts have triggers.
• Filter: an optional condition that narrows which events from the source qualify, such as only assets owned by a given team.
• Destination: where the alert is delivered, such as a Slack channel, an email address, or a webhook.

Collate evaluates each event in this order: source, then filters, then triggers. An event must pass all of them to be delivered. Each filter and trigger has an Include or Exclude setting. Include delivers the event when the condition matches. Exclude silences the event when the condition matches. When you combine several filters, each one is joined to the previous one with AND or OR. The default is AND. An Observability alert with no filters and no triggers fires on every event for its source, including asset creation and deletion. Always select at least one trigger for a focused alert.

​

Observability Alerts and Notifications

Collate has two kinds of alerts. They use the same engine and the same destinations, but they watch different things. Use an Observability alert when you want to know that a data asset is unhealthy. For example, a test case failed or an ingestion run failed. Use a Notification alert when you want to know that something changed or that someone needs to act. For example, an asset’s owner changed or an incident was assigned.

​

Which Alert Covers Incidents

Incidents are covered by Notification alerts only. An incident is a task, so it appears as a Task event:

• Use the Task source to receive task events. The only filter available for this source narrows by the users or teams mentioned in the task.
• Use the All source if you need to filter by event type, asset name, or other fields.

No Observability source reports incident status. An Observability alert on a Test Case fires when a test result is posted, which is usually at about the same time an incident is opened. It doesn’t fire when someone acknowledges, assigns, or resolves the incident. A failing test result creates an incident automatically, or reuses the incident that is already open for that test case. See Incident Manager for the workflow.

​

Observability Alerts: Sources, Triggers, and Filters

Observability alerts watch eight sources. Each source has one or more triggers and a set of filters.

​

Sources and Triggers

This table lists each source with its triggers and what each trigger fires on. The data contract status options in the UI are Success, Failed, Running, and Aborted. Collate doesn’t emit an event for a Running result, so an alert that selects only Running never fires.

​

Filters

This table lists the filters available for an Observability alert and the sources that support them.

​

Notification Alerts: Sources and Filters

Notification alerts watch 28 sources and use filters only. They have no triggers.

​

Sources

Notification alerts can watch these sources:

• All, which matches every event type
• Data assets: Table, Topic, Dashboard, Chart, Dashboard Data Model, Pipeline, ML Model, Database, Database Schema
• Services: Database Service, Dashboard Service, Messaging Service, Pipeline Service, ML Model Service, Storage Service, Metadata Service
• Ingestion: Ingestion Pipeline
• Governance: Glossary, Glossary Term, Tag, Classification, Domain, Data Product
• Collaboration: Task, Conversation, Announcement, User

​

Filters

This table lists the filters available on Notification alerts. Not every filter is available on every source:

• User doesn’t support Owner Name or General Metadata Events.
• Domain doesn’t support the Domain filter.
• Announcement supports no filters.
• Task and Conversation support Mentioned Name only.

​

Event Types

Match these event types with the Event Type filter:

• entityCreated, entityUpdated, entitySoftDeleted, entityDeleted, and entityRestored
• threadCreated, threadUpdated, postCreated, and postUpdated
• taskResolved and taskClosed
• logicalTestCaseAdded and the lineage events entityLineageAdded, entityLineageUpdated, and entityLineageDeleted, on the All source only

​

When an Alert Fires

This section explains how Collate reads events and which events fire an alert.

​

How Collate Delivers Events

When something changes in Collate, it records a change event. Each alert reads new change events on its own schedule. It applies its source, filters, and triggers, then sends the matching events to its destinations.

• New events only: an alert considers only events recorded after you create it. It doesn’t replay history.
• Polling interval: Collate checks for new events periodically. When you create an alert through the API without setting pollInterval, Collate checks every 10 seconds. Delivery is therefore near real time, not instant.
• Independent alerts: each alert tracks its own position. One event can match several alerts, and Collate delivers it once to each.
• Disabled alerts: a disabled alert doesn’t read or deliver events.
• One delivery per destination type: if an alert has several destinations of the same type, Collate sends the event once for that type to the combined recipients.
• No ordering guarantee: Collate doesn’t guarantee that events in the same polling batch are sent in the order they happened.

​

Test Cases: Every Matching Result Fires

A Test Case alert fires on every posted test result that matches the trigger, not only when the status changes.

• If a test case fails on every run and your trigger selects Failed, you receive one alert for each failed run.
• Collate doesn’t compare a result with the previous result.
• A test case that moves from Failed back to Success fires only if your trigger selects Success.

To reduce repeated alerts:

• Alert on a Test Suite instead of individual test cases. A test suite alert fires once per completed test suite run.
• Use filters (for example Domain or Owner Name) to limit which test cases notify.
• Use the incident workflow to track a failing test case as one item. Collate reuses the open incident for a test case while it keeps failing, instead of opening a new one for every run.

The status carried in the alert is the test case’s latest stored result. If you backfill an older result, the alert can show the latest result rather than the one you just posted.

​

Test Suites: One Alert Per Run

A Test Suite alert isn’t sent per test case result. Collate records one event when a test suite ingestion pipeline run finishes with a success, failed, or partialSuccess state. The event includes a summary of the results for the suite. A test suite alert with trigger Test Suite Status matches if that summary contains one of the statuses you selected.

​

Pipelines and Ingestion Pipelines

• Pipeline: Collate ignores a pipeline status that it has already recorded for the same timestamp, so a repeated report of the same run doesn’t fire again. A new or changed status fires. Collate ignores a run that ended before you created the alert.
• Ingestion Pipeline: every state change for a run produces an event, for example queued, then running, then failed. The alert fires for each event whose state you selected.

​

Schema, Metric, and Other Changes

Schema and metric triggers fire on any update to the listed fields, from any source of change, including ingestion runs. A single ingestion run that changes several columns can fire the alert more than once.

​

Data Contracts

A data contract alert fires when Collate records a validation result. A contract that includes data quality expectations can record an initial result and then another result after the quality checks finish, so one validation can produce more than one event.

​

Incidents

For incidents:

• A failing test result opens an incident for the test case, or reuses the incident that is already open.
• If automatic incident closure is enabled, a passing result resolves the open incident.
• Each incident status change, such as acknowledge, assign, or resolve, is expected to produce one entityUpdated event with entity type task.
• Log a few real events from your environment to confirm the payload before you build on it.
• A Notification alert on the Task or All source can deliver those events. See Which Alert Covers Incidents.

​

Failed Deliveries

If Collate can’t deliver an event to a destination, it records the event as a failed event and moves on. A failed delivery doesn’t block later events for that alert.

• Failed and successfully sent events are available through the alerts API.
• Collate removes old change events and delivery records according to the Data Retention application, which keeps them for 7 days by default.
• Collate doesn’t currently redeliver a failed event automatically. See Webhook Payloads and Delivery for details and how to design around it.