Notifications sent via Email, Slack, Microsoft Teams, and Webhooks now include direct links to failing rows, making it easier to investigate anomalies without navigating through multiple screens.
Group by monitors Notifications now display links for the first 10 failing groups. Non-group monitors Notifications now include a direct link to the failing rows associated with the detected anomaly.
We are excited to announce a major overhaul of the Incident Details Screen, designed to streamline your investigation workflows and provide clearer context when resolving data quality issues.
Furthermore, we are providing a preview of our upcoming Datapoints Qualifications Revamp. This initiative fundamentally changes how you provide feedback to our Machine Learning models, moving toward a dual-status system that separates model training from operational resolution.
The revamped incident screen prioritizes information based on its importance for Root Cause Analysis and impact assessment.
Based on feedback regarding the complexity of our "Feedback Loop," we are simplifying how users interact with our ML-based anomaly detection. We are splitting the qualification of data points into two distinct fields to separate Model Feedback from Operational Resolution.
Low fidelity mockup of the revamped datapoint qualification feature
We are decommissioning the "Closed - Reviewed" status for incidents now and later the "Reviewed" qualification for datapoints as part of the datapoints qualifications revamp.
Rationale:
To ensure a smooth transition, we will automatically map your historical data to the new schema:
Legacy Qualification | New Anomaly Status | New Resolution Status |
|---|---|---|
False Positive | Not Anomaly | N/A |
False Negative | Anomaly | No Action |
No Action Needed | Anomaly | No Action |
Reviewed | Not Anomaly | N/A |
Fixed | • Anomaly if outside confidence band | Fixed |
This revamp is being rollet out in 2 phases:
For any technical questions regarding how these changes affect your processed or integration, please contact your dedicated Solution Engineer or reach out to [email protected]
Starting with Sifflet CLI v0.6.0, the CLI requires Python 3.10 or newer. Python 3.8 and 3.9 are no longer supported.
Both Python 3.8 and 3.9 have reached end-of-life upstream (3.8 in October 2024, 3.9 in October 2025) and no longer receive security updates from the Python core team.
pipx upgrade sifflet will keep working as usual.pipx install --python python3.10 siffletIf you stay on Python 3.8 or 3.9, future CLI updates will no longer install, pipx upgrade sifflet will fail. If you keep using sifflet==0.5.0, it will not receive new features or bug fixes.
Who is most affected
Customers using the Sifflet CLI for any task, like Monitor as Code. The updated requirements are also reflected in our public documentation.
Sifflet now uses a schedule-aware lookback window when grouping monitor failures into existing incidents. Previously, the grouping engine always searched back up to 7 days to find a candidate incident to attach a new failure to - regardless of how frequently the monitor actually ran. This could result in hourly monitors being incorrectly grouped with stale incidents from days earlier, or monthly monitors being grouped too conservatively.
The lookback window is now dynamic, automatically calibrated to the monitor's run frequency:
| Monitor frequency | Lookback window (Last incident failure) |
|---|---|
| Hourly (or more frequent) | 12 hours |
| Daily | 3 days |
| Weekly | 3 weeks |
| Monthly | 3 months |
Incident grouping is most useful when it surfaces related failures that are genuinely likely to share a root cause. A failure on an hourly monitor that happened 5 days ago is almost certainly unrelated to today's failure - grouping them creates noise rather than signal.
By aligning the lookback window with the monitor's natural cadence, Sifflet ensures that grouped incidents reflect temporally coherent failure patterns, making it easier for data teams to investigate root causes and avoid being distracted by outdated context.
All users who rely on incident grouping. The change is applied automatically - no configuration is required.
Part of the Incident Centric Alerting initiative, aimed at making incident notifications more actionable and reducing alert fatigue.
We are updating how Data Product notifications work to reduce alert noise and provide clearer business-level visibility.
This update is designed to reduce alert fatigue and provide more meaningful, business-focused notifications instead of monitor-level noise.
Existing workflows that rely on notification tools (such as Slack, email, etc.), ticketing systems (such as Jira or ServiceNow), or other integrations configured directly on Data Products may need to be updated.
For users who already have notification settings configured on Data Products, a feature flag will be applied to ensure that nothing changes until your migration is completed.
Please review any notification processes currently depending on the Data Product before this change is released, the release of this new feature is plan by the end of June. We recommend migrating existing configurations to the new Notification Rules system.
If you are unsure how to migrate your current setup or how this change may impact your use case, please contact your Customer Success representative for guidance and migration support or contact the support team to [email protected].
We’re introducing Sifflet AI Chat , your collaborative assistant for data reliability and platform guidance.
Learn more about here.
We’ve introduced Notification Rules, a new way to manage alerts and incident routing across monitors from one centralized location. Instead of configuring notifications monitor by monitor, you can now create reusable rules that apply to multiple assets or monitors at once.
Notification Rules let you define what triggers alerts (matching monitors/assets) and where those alerts are sent.
Example:
You manage the Sales domain and want to monitor payment tables.
You create a rule for payment_transactions, invoices, and refunds, focusing on Freshness and Volume.
Now, whenever an issue occurs, alerts are automatically sent to #finance-alerts, finance-ops@company , and Jira using the FINOPS template, so your team can react quickly and avoid impacting financial reporting.
Notification Rules make alerting in Sifflet more scalable, consistent, and easier to maintain ,while helping teams respond faster to incidents.
Learn more about it here.
The Feature is available but the override of the global notifications is set on all existing monitors (with or without existing notifications in them).
You can create global notifications rules but they won't apply on existing monitors (unless the override is manually removed for the monitor). They will apply on newly created monitors without any override defined.
Any monitor without any custom notifications will have the override setting turned off, this will allow roll out of the global notification rules on existing monitors , without impacting monitor with existing settings.
The incident creation setting will now be independent from the custom notifications settings and turn on by default for new monitors.
Two options would available for bulk edition of monitors:
v659
We’ve introduced a first improvement to help you better track incidents at the Data Product level.
You can now view all incidents related to a specific Data Product in a dedicated list. From this list, you can click on any incident to open the Incident Overview page directly.
We’ve made a few improvements to the integration setup experience:
The Credentials menu has been moved under Settings. Permissions remain unchanged .
You can now create and edit credentials directly from the integration creation page, making the setup process smoother and faster.
v642
We’ve improved the domain and subdomain selector to make navigation faster and easier, especially for large lists.
Find domains and subdomains instantly with search, eliminating the need to scroll through long lists.
