Being alerted by monitors allows you to be proactive about issues detected by Sifflet and to react before the issue impacts your teams and any decision they might be about to make. It also allows you to be alerted in case of a monitor misconfiguration to ensure that it doesn't go unnoticed and that your monitoring coverage remains intact.

📘

Before setting notifications, make sure to set up alerting channels

📘 Before setting notifications, make sure to set up your destinations

Before any notification can be sent, the channels you want to use need to be connected in Collaboration Tools.

How monitors get notifications

A monitor sends notifications to the destinations defined by:

1. The notification rules that match it. This is the recommended approach: one rule routes notifications for a whole group of assets or monitors, and new monitors inherit matching rules automatically.
2. A monitor-level override, called custom notifications, when one monitor needs special handling.

Notifications are triggered when a monitor run ends with the status Failure, Requires attention or Technical error, and when a failing monitor recovers. What you receive depends on whether the failure creates or joins an incident. See the Notifications overview and the Notification catalog.

Monitor-Level Setup

Notification settings are available as the last step of the manual monitor configuration, and can be revisited at any time. Use them to:

• Override the destinations inherited from notification rules and choose other channels for this monitor.
• Customize the alert message, to give the recipients guidance on what to do when this particular monitor fails.
• Choose whether a failure creates an incident (enabled by default on new monitors).

The channels you can choose from are those connected by an Admin in Collaboration Tools.

Muting Notifications

The "Pause Notifications" feature allows you to temporarily silence alerts for a specific monitor. This is useful when you anticipate temporary or expected status changes (like during a planned maintenance window) and want to avoid unnecessary noise without risking missing the next important update.

How It Works

When you pause notifications, the monitor will stop sending alerts until one of two conditions is met:

1. Automatic Resumption: The monitor will automatically resume sending notifications as soon as its status improves to Passing (from Failing or Needs Attention). A change from Failing to Needs Attention does not resume notifications. This ensures you are notified of the next failure after the monitor recovers.
2. Manual Resumption: You can manually resume notifications at any time by clicking the button again.

How to Pause Notifications

1. Navigate to the monitor you wish to silence.
2. Click the Pause Notifications icon (e.g., a bell symbol). The tooltip confirms the action: "Pause notifications until next status change."
3. The monitor is now paused. To resume notifications manually before a status change occurs, click the icon again.

Notifications Best Practices

Pick the Right Alerting Channels

• Make sure to pick the appropriate channels depending on the severity of your monitor: if your teams are usually more reactive on Slack or MS Teams, you probably want to have your monitors with the highest severity notify over there and keep emails for the least critical monitors. Keep in mind that recovery notifications are not sent by email.
• Be mindful of single points of failure: notifying a single person over email is nice as it gives clear ownership, but you should also account for cases where the usual owner of a monitor/data asset might be out: somebody else on the team needs to be able to see the alert and react accordingly if needed.
• Notifications are not only useful to let data owners know that something needs to be fixed, they can also allow you to give visibility to data consumers about the health of upstream pipelines.

Make the Alert Actionable

• Ensure that your notification message includes the necessary context to facilitate troubleshooting. For example, you can include the following information in your notifications:
  • Debugging guidelines
  • Internal documentation links

As Code

Parameters

In notifications

kind: The kind of notification hook you're setting up in the monitor.

name: The name of the collaboration channel or the email.

notifications:
- kind: Slack
  name: auto-demo
- kind: Slack
  name: auto-demo-slack
- kind: Email
  name: [email protected]
- kind: MicrosoftTeams
  name: General

incident.message: A custom message that will be added to alerts

incident:
  severity: Low
  message: Check the upstream pipeline status before investigating this table.
  createOnFailure: false