Two products, two alert systems, and they cover different failures. DataOps TestGen alerts on the data: a failed test, a new hygiene issue, a monitor anomaly, a score drop. DataOps Observability alerts on the pipeline: a failed task, a late run, a journey that ran out of order. Send both to the same Slack channel and one person sees the pipeline failure and the bad data it caused.
This page covers the mechanics, which are the same for every database and file source TestGen supports. Where data alerts sit next to Datadog and other app monitoring is in the Datadog answer, and tuning them so people still read them is in the false-positive answer.
Which channels ship
| Channel | DataOps TestGen | DataOps Observability |
|---|---|---|
| Email destination; needs an SMTP server configured | Send email action | |
| Slack | Slack destination, through an incoming webhook | Web request to a Slack incoming webhook (walkthrough) |
| Microsoft Teams | Teams destination, through the Workflows app | Web request to a Teams webhook (walkthrough) |
| Jira | Generic webhook to a Jira automation rule | Web request to a Jira automation rule (walkthrough) |
| Any other HTTPS endpoint | Generic webhook, JSON, optional authorization header | Web request, your method, payload, and headers |
| PagerDuty | Not documented | Not documented |
Sources: TestGen notifications and Observability rules, checked October 2026. Slack, Teams, and webhook destinations arrived in TestGen’s October 14, 2026 release.
One Teams detail. TestGen’s docs use the Workflows app. Observability’s walkthrough uses an incoming webhook connector URL, and Microsoft’s own Teams docs say those connectors are nearing deprecation. The same Microsoft page says Workflows accepts the Message Card format the Observability walkthrough sends, so start new channels on Workflows.
What sets them off
| Product | Event | Triggers |
|---|---|---|
| TestGen | Test run | Always; on failures; on failures and warnings; on new failures and warnings |
| TestGen | Profiling run | Always; on new hygiene issues |
| TestGen | Monitors | On anomalies, per table group, optionally per table |
| TestGen | Score drop | Total or CDE score falls below a threshold you set |
| Observability | Task status | Failed, completed, running, or completed with warnings |
| Observability | Runs | Run status, late start, late end, missing, after N in a row |
| Observability | Test outcomes, log matches, instance alerts | Failed, warning, or passed tests; log level and regex; out-of-sequence or incomplete instances, datasets not ready |
TestGen destinations are set once per project and shared by every rule. Observability rules live on a journey (Define Rules), and task status rules fire only for batch pipeline components.
A failed test to a Jira work item
This one is documented end to end in Create Jira work items. It’s a webhook, not a native integration:
- In Jira Cloud, create an automation rule with an Incoming webhook trigger, a condition that
{{webhookData.event}}doesn’t equaltest, and a Create work item action with Summary set to{{webhookData.summary}}. - Save without enabling, generate the trigger’s secret, then turn the rule on.
- In TestGen, add a Generic webhook destination with the Jira URL, header name
X-Automation-Webhook-Token, and the secret as its value. - Click Send Test. Jira’s audit log shows a run that stopped at the condition.
- Add a test run rule that uses the destination.
Pick the trigger with care. Each notification creates one work item, so a suite that fails every night opens a ticket every night. The docs recommend On new test failures and warnings. A hygiene issue takes the same path through a profiling run rule set to On new hygiene issues. The payload lists up to 20 failures or issues, with a link to the rest.
Observability’s Jira walkthrough does the same for pipelines: when a task fails, a POST to the Jira automation webhook opens a Bug with the project, pipeline, run, and a link back.
Before you rely on it
TestGen refuses webhooks to private and reserved network addresses. A self-hosted chat server needs its host in TG_WEBHOOK_ALLOWED_HOSTS. Deleting a destination deletes every rule that uses it.
A ticket isn’t always the right home for the conversation. TestGen keeps timestamped notes on each test, so the decision to raise a threshold stays with the test. And DataKitchen’s MCP agent post lays out a third route: an agent that reads failures and files tickets only for the ones it shouldn’t fix.
Documentation: TestGen Notifications, Create Jira work items, Observability Rules, Define Rules, Rule Triggers, Web Request, Slack, Teams, and Jira walkthroughs