Frequently asked questions

A monitor alert is a per-asset failure notification configured on a single monitor, while a notification rule is a reusable, centralized policy that routes failures from many monitors to the right destinations based on matching conditions. Notification rules eliminate the need to configure alerting on every monitor individually, making alerting management practical at scale. Read how notification rules work or explore Sifflet's monitoring platform.

Yes—Sifflet notification rules can be scoped by domain, tag, or asset ownership, so different teams receive only the alerts relevant to their slice of the data platform. This makes it practical for large organizations to give each domain team its own alerting policy without creating conflicts with company-wide rules. Learn more about notification rules or book a demo to explore enterprise configurations.

Sifflet notification rules can route alerts directly to Jira (creating tickets automatically) or any external system via webhook, in addition to Slack and email—making it easy to plug data quality incidents into existing engineering workflows without manual handoffs. This means on-call engineers receive structured, routable incidents rather than raw monitor alerts. See the full guide to notification rules or explore Sifflet's integration capabilities.

Notification rules in Sifflet support condition-based filters that can target monitors by asset type, tag, data domain, or severity level—giving teams precise control over which alerts get routed where. Each rule answers two core questions: what triggers an alert (matching conditions) and where it goes (Slack, email, Jira, or webhook). Read the deep dive on notification rules or explore Sifflet's monitoring features.

Sifflet notification rules use condition-based matching so a single rule can cover hundreds or thousands of monitors at once—without any per-monitor configuration required. As your data stack grows, new monitors that match an existing rule's conditions are automatically covered, meaning your alerting policy scales with your infrastructure at no extra overhead. Learn how notification rules work or book a demo to see them in action.

By surfacing every incident scoped to a specific Data Product, Sifflet turns Data Products from abstract groupings into accountable, observable units—each with a clear owner who sees failures the moment they happen. This shifts data quality from a diffuse, shared responsibility to a product-level one, mirroring how software teams own service reliability. Read the full announcement or book a demo to see it in action.

Each incident shown in the Data Product incident list links directly to Sifflet's Incident Overview page, which includes the lineage graph—showing exactly which upstream sources caused the failure and which downstream consumers are at risk. Data product owners get both the scope and the root cause without switching tools. See how it works and explore end-to-end data lineage in Sifflet.

When incidents are grouped by Data Product, engineers immediately see which upstream assets are failing and can trace the blast radius through the product's lineage graph—rather than piecing together alerts from individual monitors. This turns hours of manual triage into a focused investigation. Explore Sifflet's lineage capabilities and learn how Data Product Incident Visibility works.

Sifflet surfaces any incident—schema changes, freshness failures, volume anomalies, or custom rule violations—that affects any asset belonging to a given Data Product, all in a single consolidated list. Each incident links directly to the full Incident Overview page with lineage context attached, so teams can understand downstream impact immediately. Read the full overview or see how Sifflet monitoring works.

Data Product Incident Visibility helps data teams meet SLAs by making every incident affecting a Data Product immediately visible in one place, dramatically reducing the time between failure detection and resolution. Instead of chasing individual monitor pages, product owners see the full scope of an issue in seconds and can escalate with confidence. Learn how the feature works or explore Sifflet's monitoring capabilities.

Sifflet notification rules can route alerts to Slack channels, email addresses, Jira (automatically creating issues on failure), and generic webhooks for custom integrations — covering the most common incident-management workflows without requiring a new tool. This means data teams receive alerts exactly where they already work. See how to configure each destination, or book a demo to see the alerting system in action.

Per-monitor settings attach alert routing to a single monitor and must be maintained one by one as monitors are added or updated — a brittle approach at scale. Notification rules are defined centrally, matched against monitors by condition, and automatically inherited by any new monitor that meets the criteria; individual monitors can still override or supplement inherited rules for edge cases. Explore the full comparison in this Sifflet article.

Per-monitor alert configuration becomes unmanageable as a data platform grows — with hundreds of monitors, ensuring every one has the right recipients requires constant manual upkeep and is error-prone. Centralized notification rules let teams define routing logic once, organized by domain or data product, and have it apply automatically to all current and future matching monitors. See how Sifflet's notification rules scale your alerting, or book a demo to explore them live.

Each notification rule in Sifflet has two halves: a matching condition that filters which monitors trigger it (by asset, domain, tag, or monitor type) and an action set that defines where alerts are delivered. When a monitor fails and matches the rule, Sifflet executes the action automatically — and any new monitor matching an existing rule inherits it with no additional setup required. Learn how to configure notification rules as part of your data observability practice.

Notification rules in Sifflet are reusable alerting policies that route monitor failures to destinations like Slack, email, Jira, or webhooks — applied across many assets at once rather than configured on each monitor individually. Each rule specifies a matching condition (which assets, domains, or tags trigger it) and an action set (where the alert is delivered). Read the full breakdown of Sifflet's notification rules.

Navigate to any Data Product page inside Sifflet's data catalog and scroll to the Incidents section — it lists every active and recent incident affecting the assets and pipelines within that product, and each row links to the full Incident Overview with lineage and ownership context. Explore the Sifflet catalog or request a demo to see Data Product Incident Visibility in action.

Monitoring individual assets tells you whether a specific table or pipeline is healthy, but gives no direct answer about whether the Data Product built on those assets is meeting its SLA. Data Product Incident Visibility in Sifflet aggregates all asset-level incidents upward so product owners get a unified view rather than a patchwork of separate monitor pages. Explore Sifflet's product monitoring capabilities and how they connect to the Data Product incident layer.

Tracking incidents at the Data Product level transforms a conceptual grouping into an accountable, operational unit with a real-time status board. Without product-level incident aggregation, data product owners must manually correlate failures across dozens of individual asset monitors — a process that delays resolution and inflates mean time to recovery. See how Sifflet's Data Product Incident Visibility solves this, or book a demo to see it live.

Each Data Product page in Sifflet includes a dedicated Incidents section that lists every active and recent incident affecting any asset inside that product. Clicking any incident opens the full Incident Overview — with lineage context, owner details, and resolution history — so data product owners can act immediately without correlating failures across separate monitor pages. Explore how Sifflet's data catalog organizes Data Products and surfaces incidents in one place.

Data Product Incident Visibility is a Sifflet feature that consolidates every incident affecting a specific Data Product into a single, dedicated list — eliminating the need to check each individual asset monitor separately. From that list, any incident links directly to the full Incident Overview page with lineage, owner, and resolution context attached. Learn more about how it works in this Sifflet overview.

Data Product Incident Visibility is available now to all Sifflet customers with no extra configuration required. Open any existing Data Product in Sifflet and switch to the Incidents tab to see the live incident list immediately. If you haven't defined Data Products yet, go to the Data Products section and list the datasets, dashboards, and pipelines that comprise each product — incidents will roll up automatically from that point. Book a demo to walk through the setup with a solution engineer.

Asset-level incident views are designed for platform engineers triaging individual tables — they have no roll-up to business outcomes. Product-level views aggregate incidents from all underlying datasets, dashboards, and pipelines that make up a Data Product, making them the right interface for product owners tracking SLAs. If a Data Product has not yet been defined, the product-level view is unavailable, so teams should define Data Products first. See the full comparison table in the article.

Most data observability platforms organize incidents by table or pipeline, which works for platform engineers but leaves business owners manually mapping failures back to the product they care about. Product-level visibility removes that burden: Data Product owners see a focused, noise-free list scoped to their domain, enabling faster SLA reporting, clearer cross-team accountability, and faster incident routing without tribal knowledge. Read the full breakdown of operational impact.

Sifflet adds an Incidents section to each Data Product page that lists every active and recent incident affecting any underlying asset. The list updates in real time when a freshness or volume monitor fires, and lets you filter by status, severity, or owner, sort by detection time or type, and drill into the full Incident Overview with lineage attached — all without leaving the product context. See the full feature walkthrough.

Data Product Incident Visibility is a Sifflet feature that consolidates every incident affecting a specific Data Product into a single dedicated list on the Data Product page. Instead of manually clicking through individual asset monitor pages, product owners see one unified view — filterable by status, severity, or owner — with click-through to the full Incident Overview including lineage and resolution context. Learn more about the feature in the full announcement.

Data Product Incident Visibility is available now to all Sifflet customers. Open any existing Data Product and switch to the Incidents tab to view the live incident list. Teams that haven't defined Data Products yet can do so from the Data Products section. For a personalized walkthrough, book a demo with our solution engineers.

Data Product Incident Visibility enables three key workflows: SLA reporting where owners can pull incident lists without writing custom queries, faster incident routing where triagers don't need to manually map assets back to their parent product, and cross-team accountability where consumers can subscribe to a Data Product and see exactly what is breaking it.

A Data Product in Sifflet is a curated set of datasets, dashboards, or pipelines that delivers defined value to a business consumer. Examples include customer 360 models, marketing attribution tables, revenue forecast dashboards, or feature stores. Treating data as a product means giving it owners, SLAs, and quality expectations.

Asset-level incident views are designed for platform engineers but don't roll up to business outcomes. Data Product Incident Visibility flips the lens to show data product owners a single, focused incident list scoped to their domain, eliminating sifting through unrelated noise from elsewhere in the data catalog.

Data Product Incident Visibility is a Sifflet feature that lets you view every incident affecting a specific Data Product in a single dedicated list. This reframes Data Products from conceptual organizing principles into operational, observable units. Learn more in the full article.

Data Product Incident Visibility is built into Sifflet's incident management system. All incidents created in Sifflet are automatically associated with their related Data Products, ensuring complete visibility without requiring manual setup or integration with external tools.

Data Product owners, analytics teams, data engineers, and anyone responsible for maintaining data quality and reliability benefit from this feature. It's especially valuable for organizations with multiple downstream consumers depending on their data products, as it provides quick visibility into product health and enables faster incident response.

By making Data Products observable units with clear incident visibility, this feature enables better data governance. Teams can track the health and reliability of their data products, establish clear ownership and accountability, and implement consistent incident response practices across the organization.

Yes. Data Product Incident Visibility shows you every incident associated with a specific Data Product. If an incident affects multiple data products, it will appear in the incident lists for each affected product, helping you understand the full scope of impact across your data ecosystem.

The incident list shows all incidents associated with a Data Product. When you open an incident from the list, you access the full Incident Overview page which includes lineage context, owner information, and resolution details to help you understand the impact and resolve issues faster.

By surfacing every incident affecting a specific Data Product in a single focused list, Data Product Incident Visibility eliminates context switching. Users can quickly assess the health of their data products, understand which incidents need attention, and access full incident context including lineage and owner information without navigating multiple pages.

Data Product Incident Visibility transforms Data Products from abstract concepts into accountable, observable units. Instead of manually clicking through multiple monitor pages and reconciling incident data across different views, teams can now see all incidents affecting their data products in one place, enabling faster incident response and better data governance.

Data Product Incident Visibility is a Sifflet feature that lets users view every incident affecting a specific Data Product in a single dedicated list. From that list, any incident opens directly into the full Incident Overview page, with lineage, owner, and resolution context attached.

This feature unlocks three concrete workflows: (1) SLA reporting where owners can pull the incident list for any time window and report against agreed-upon reliability targets; (2) Faster incident routing where triagers no longer need to mentally map failing assets back to their parent product; (3) Cross-team accountability where consumers can subscribe to a Data Product and see exactly what is breaking it.

Most data observability platforms organize incidents by table or pipeline, which works for platform teams but fails business owners who only care about whether their product is healthy. Product-level visibility flips the lens so the Data Product owner sees a single, focused incident list scoped to their domain without sifting through unrelated noise from elsewhere in the warehouse.

Each Data Product page in Sifflet includes an Incidents section that lists every active and recent incident affecting any asset inside the product. Users can filter by status, severity, or owner, sort by detection time or incident type, and click through to the standard Incident Overview for triage with full lineage from source to consumer. The list updates in real time.

A Data Product in Sifflet is a curated set of datasets, dashboards, or pipelines that delivers a defined value to a business consumer. Examples include a customer 360 model, a marketing attribution table, a revenue forecast dashboard, or the feature store powering a recommendation system.

Data Product Incident Visibility is a Sifflet feature that lets users view every incident affecting a specific Data Product in a single dedicated list. From that list, any incident opens directly into the full Incident Overview page, with lineage, owner, and resolution context attached.

Centralized notification rules solve three key problems: Setup effort (configured once per pattern instead of per monitor), Consistency (inherited automatically instead of drifting as the monitor catalog grows), and Visibility (surfaced in Monitor and Incident overviews instead of scattered across hundreds of individual configurations). At scale, when managing hundreds of monitors, these differences compound significantly. Rules also ensure new monitors automatically adopt appropriate routing without requiring manual setup.

Notification rules are available now to all Sifflet customers. Existing monitor-level notifications continue to work, so teams can migrate gradually rather than all at once. Start by identifying one high-volume domain (such as payments, customer data, or marketing attribution) and replace its per-monitor configurations with a single rule. Measure the change in alert noise after one week. See the Sifflet documentation for detailed guidance on rule creation, matching syntax, and override behavior.

Yes. When a monitor fails and matches a notification rule, Sifflet automatically creates a corresponding incident by default. This closes the gap between receiving an alert and opening a tracked incident. Every routed alert now has a tracked incident with full lineage, history, owner, and resolution context attached, connecting the workflow from alert to triage seamlessly.

Notification rules match based on composable conditions including assets, domains, monitor types, and tags. This flexibility allows you to define rules in whatever way makes sense for your organization's structure. For example, you could have a rule that matches all Freshness and Volume monitors on payment-related tables, or all monitors tagged with 'critical' across all domains.

Notification rules support multiple channels including Slack, email, Jira, and webhooks. This allows you to route alerts to the right destination for each situation — whether that's a Slack channel for real-time team visibility, email for documentation, Jira for formal ticket creation, or a custom webhook for integration with other tools in your stack.

Yes. Notification rules provide both inheritance and override. Any individual monitor can opt out of inherited behavior or layer in additional recipients for edge cases. This means you get the benefits of centralized configuration while maintaining flexibility for exceptions that need special handling.

Per-monitor notifications require configuration on every single monitor individually, which doesn't scale. Notification rules define routing once and apply it across many assets automatically. New monitors that match an existing rule inherit the notification configuration automatically with no setup required. This eliminates configuration drift and reduces setup effort dramatically — especially at scale when managing hundreds or thousands of monitors.

Notification rules in Sifflet are reusable alerting policies that route monitor failures to the right destinations across many assets at once. Each rule answers two questions: what triggers an alert (which monitors or assets match) and where the alert is delivered (Slack, email, Jira, or a webhook). They replace per-monitor notification configuration with a centralized system that mirrors how the business is actually organized — by domain, by data product, or by team.

Data Product Incident Visibility is designed for product owners, data consumers, and teams adopting a data-as-a-product model. It is particularly valuable for SREs managing incident rotations, data teams needing to report SLA compliance, and business consumers who want to understand the reliability of the data products they depend on.

Yes. The Data Product Incidents section allows you to filter by status, severity, or owner so an SRE rotation can scope to active high-severity issues only. You can also sort by detection time or incident type to see what just broke versus what has been simmering over time.

Yes. Once a Data Product is defined in Sifflet by listing the datasets, dashboards, and pipelines that comprise it, every incident affecting any underlying asset rolls up automatically to that product. No manual configuration or mapping is required—when a freshness or volume monitor on any table fires, the Data Product surface reflects it immediately in real time.

Asset-level incidents work best for platform engineers triaging individual tables but offer no clear roll-up to business outcomes. Pipeline-level incidents suit data engineers responsible for ETL reliability but miss dashboard and ML asset failures. Data Product incidents are best for product owners and consumers tracking SLAs and provide a complete view of product health, though they require Data Products to be defined first.

Data Product Incident Visibility is available now to all Sifflet customers. Open any existing Data Product in Sifflet and switch to the Incidents tab to see the live list. Teams that have not yet defined Data Products can do so from the Data Products section. Once a product is defined by listing the datasets, dashboards, and pipelines that comprise it, every incident affecting any underlying asset rolls up automatically with no extra configuration required.

Data Product Incident Visibility unlocks three concrete workflows: (1) SLA reporting - owners can pull the incident list for any time window and report against agreed-upon reliability targets without writing custom queries; (2) Faster incident routing - triagers no longer need to mentally map a failing asset back to its parent product; (3) Cross-team accountability - consumers can subscribe to a Data Product and see exactly what is breaking it.

Most data observability platforms organize incidents by table or pipeline, which works for platform teams but fails business owners who only care about whether their product is healthy. Product-level visibility flips the lens: the Data Product owner sees a single, focused incident list scoped to their domain without sifting through unrelated noise from elsewhere in the warehouse.

Each Data Product page in Sifflet includes an Incidents section that lists every active and recent incident affecting any asset inside the product. Users can filter by status, severity, or owner, sort by detection time or incident type, and click through to the standard Incident Overview for triage with full lineage from source to consumer. The list updates in real time.

A Data Product in Sifflet is a curated set of datasets, dashboards, or pipelines that delivers a defined value to a business consumer. Examples include a customer 360 model, a marketing attribution table, a revenue forecast dashboard, or the feature store powering a recommendation system.

Data Product Incident Visibility is a Sifflet feature that lets users view every incident affecting a specific Data Product in a single dedicated list. From that list, any incident opens directly into the full Incident Overview page, with lineage, owner, and resolution context attached.

Per-monitor alert configuration breaks down quickly, creating fragmented setups across hundreds of monitors, inconsistent escalation paths, and onboarding friction for new engineers. Notification rules solve this by establishing a single source of truth for alert routing that automatically applies to new monitors, eliminates drift, and surfaces rule visibility directly in Monitor and Incident overviews. At scale, this transforms alerting from a tedious per-monitor chore into a managed, observable system. Learn more about scaling data observability in our guide.

When a monitor fails and matches a notification rule, Sifflet automatically creates a corresponding incident with full lineage, history, owner, and resolution context attached. This closes the critical gap between alert and triage—operators no longer need to manually create an incident after seeing a Slack message. The Slack alert links directly to the incident, the incident links to the failing asset, and the asset links to its complete data lineage, giving your team a complete picture in three clicks.

Yes. While any new monitor matching a rule automatically inherits its settings, individual monitors can opt out of inherited behavior or layer in additional recipients for edge cases. This flexibility means you get the efficiency of centralized rules while maintaining the ability to customize critical or unusual monitors. Overrides ensure your alerting strategy remains both consistent and adaptable as your stack evolves. Explore how this works in the full notification rules documentation.

By replacing per-monitor notification setup with a centralized system that mirrors how your business is actually organized—by domain, data product, or team—notification rules eliminate fragmented configurations that scale poorly. New monitors matching an existing rule automatically inherit the rule's settings without manual setup. This consistency reduces duplicate alerts, ensures alerts land in the right channels, and prevents on-call engineers from being paged across disconnected systems. See how Sifflet's data observability platform applies this at scale.

Notification rules in Sifflet are reusable alerting policies that route monitor failures to the right destinations across many assets at once. Each rule answers two core questions: what triggers an alert (which monitors or assets match) and where the alert is delivered (Slack, email, Jira, or a webhook). Unlike per-monitor notification configuration, rules let teams centralize their alerting strategy and apply it automatically across hundreds of monitors. Learn more in our complete guide to notification rules.