Automatic Incident Grouping

When a data quality monitor fails, our platform works to minimize alert fatigue and help you focus on the root cause of a data problem. Instead of creating a new, isolated incident for every single failure, the system analyzes your Dataset Lineage and existing open incidents. If a relevant incident is found, the new failure is grouped into it.

This page explains the logic behind this powerful feature.

How It Works

When a monitor in Sifflet fails (the "New Failure"), Sifflet performs a multi-step analysis to determine if it should be grouped with an existing issue or if a new incident should be created.

1. Look for Recent Incidents: Sifflet searches the most recent open incidents that have had a new failure within the last 7 days.
2. Analyze Relationships: It then analyzes the new monitor failure to see if it's related to any of these recent incidents based on two key factors:
   • Semantic Match: It checks if the monitor template of the active incident is a compatible match for the monitor template of the new failure, based on their positional relationship (see Grouping Rules below). Not all failures in a lineage are related; for example, a Freshness delay often causes a Volume issue, but a Schema Change is likely unrelated to an Email Format error.
   • Data Lineage: Whether the monitors are on the same asset, or on assets connected via upstream, downstream, or sibling lineage, within a maximum lineage depth of 3 hops.
3. AI Validation (Relevance Check): Sifflet uses an AI model to validate the potential connection, analyzing the context of both the new failure and the existing incident to confirm if they are truly related.
4. Group or Create:
   • If a strong relationship is found, the new monitor failure is added to the existing incident.
   • If no related incident is found, a new incident is created.

Grouping Rules

Sifflet uses the following logic to determine if monitor failures are related. Grouping is heavily dependent on the monitor template of the new failure and its positional relationship to the monitors already on the existing incident:

• Same Asset — the new failure is on the exact same asset as an existing incident's monitor.
• Upstream Asset — what upstream failures could have caused this incident? Infrastructure failures (Volume, Freshness) are valid causes of almost any downstream failure. For SQL, only infrastructure upstream applies — a business rule failing upstream doesn't cause your business rule to fail.
• Downstream Asset — what downstream failures are likely effects of this incident? This is more conservative than upstream: business and format monitors downstream are almost always independent.
• Sibling Asset — what sibling failures are likely co-symptoms of the same root cause? Two assets are considered siblings if they share a parent asset of the same type (Dataset), or if they are both root assets (i.e. neither has a parent asset). Infrastructure monitor types have the strongest sibling correlation; format validators and business logic monitors have near-zero sibling correlation.

A new monitor failure is grouped into an existing incident only if the existing incident contains a monitor of one of the compatible templates listed for the corresponding relationship (same asset, upstream, downstream, or sibling), within a maximum lineage depth of 3 hops.

AI-Generated Incident Descriptions

When incidents are automatically grouped or a new monitor is linked to an existing incident, Sifflet uses AI to generate a clear, human-readable description of the incident. This description summarizes the failures and provides context, helping you quickly understand the issue.