Notification Rules in Sifflet: Centralized Alerting at Scale

Notification rules in Sifflet are reusable alerting configurations that route monitor failures to the right destinations across many assets at once. Each rule defines two things: what triggers the alert (which monitors or assets match) and where the alert is sent.

Before this update, every monitor carried its own notification settings. Now one rule can cover an entire domain, asset group, or monitor type — and any new monitor that matches the rule inherits it automatically.

What are notification rules?

A notification rule is a centralized alerting policy that maps a set of monitors to a set of delivery channels. It removes the need to configure Slack, email, or Jira destinations on each monitor individually.

Rules let teams enforce consistent alerting behavior across the platform. They also keep configuration in one place, so escalation paths do not drift as new monitors are added.

How notification rules work

Each notification rule has two halves: a matching condition and an action set. When a monitor fails and matches a rule, Sifflet executes the action.

• Matching condition: based on assets, domains, monitor types, or tags.
• Action set: the channels and templates used to deliver the alert.
• Inheritance: new monitors that match an existing rule pick it up automatically.
• Override: any individual monitor can opt out of inherited behavior or layer in extra recipients.

Automatic incident creation

When a monitor fails and matches a notification rule, Sifflet creates a corresponding incident by default. Every routed alert therefore has a tracked incident with full lineage, history, and resolution context.

This default closes the gap between alert and investigation. Operators no longer need to manually open an incident after seeing a Slack message — the workflow is connected from the start.

Visibility in monitor and incident overviews

Applied notification rules now appear directly in the Monitor Overview and Incident Overview pages. Operators can see which rule fired, which channels were notified, and who owns the response in a single view.

This visibility is critical for on-call rotations. When a Slack alert lands at 3 a.m., the responder can trace exactly which rule triggered it and why — without piecing together monitor-level configuration.

Example: routing payment monitors to finance

A data engineer managing a Sales domain creates a single rule that targets the payment_transactions, invoices, and refunds tables, scoped to Freshness and Volume monitors. The rule routes alerts to:

• The #finance-alerts Slack channel
• The finance-ops@company email distribution list
• Jira, using the FINOPS ticket template

When a new payment-related monitor is added next quarter, no notification setup is required. The rule applies automatically.

Why centralized rules matter at scale

Per-monitor alert configuration breaks down quickly. A platform with 500 monitors accumulates 500 fragmented configurations, drift between similar assets, and inconsistent escalation paths.

Centralized rules solve three problems at once.

ProblemWithout rulesWith notification rulesSetup effortConfigured per monitorConfigured once per patternConsistencyDrifts as monitors growInherited automaticallyVisibilityScattered across monitorsShown in Monitor and Incident overviews

Getting started

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.

The Sifflet documentation walks through rule creation, matching syntax, and override behavior. For teams running data observability at scale, centralized notification rules turn alerting from a per-monitor chore into a managed system.