Notifications overview
Notifications make sure the right people hear about a data quality problem as soon as it is detected, with enough context to act on it. This page explains how Sifflet decides what to send, where to send it, and what the message is about.
How a notification is sent
- A notification rule (or a monitor-level override) selects one or more destinations.
- Each destination is a channel configured in Collaboration Tools: Slack, Email, Microsoft Teams, Google Chat or a Webhook.
- Slack, Email, Microsoft Teams and Google Chat messages are rendered from a template specific to each channel. The same notification looks different on each channel but says the same thing.
- Webhooks are not templated: they receive a JSON payload. See Webhooks for the payloads.
Incident-centric and monitor-centric notifications
Sifflet sends two kinds of notifications. What differs is the subject of the message.
| Kind | The message is about | Typical case |
|---|---|---|
| Incident-centric | The incident | A monitor fails and an incident is created, or the failure is grouped into an incident that already exists. |
| Monitor-centric | The monitor and its latest run | A monitor fails, needs attention or recovers and no incident is involved. |
Incident-centric notifications
When a failing monitor creates or joins an incident, you are notified about the incident:
- Incident created: a new incident has been opened, with the monitor that opened it.
- Incident updated: another monitor was added to an incident that already existed, so related failures are reported together instead of as unrelated alerts. See Incident auto-grouping.
- Incident closed: the incident is closed. This notification is sent to every channel the incident has notified so far, not only the one that opened it.
- Monitor recovered: the monitor is passing again, after failing or needing attention.
- Assignee added: an email is sent to each user newly assigned to an incident, including users reached through a team assignment.
For incidents, a notification is only sent for the first failed run of a monitor. Subsequent failed runs of the same monitor do not trigger additional notifications until the incident is closed.
Monitor-centric notifications
When a monitor does not create an incident, or when its status changes, you are notified about the monitor:
- Monitor failure: a monitor run failed its threshold.
- Monitor needs attention: a run could not reach a verdict, because of a technical error or because it requires a human look.
- Monitor recovered: the monitor is passing again, after failing or needing attention.
- Monitor success: a successful run. Sent to webhooks only.
The full list, channel by channel, is in the Notification catalog.
Webhooks are neither incident-centric nor monitor-centric: each payload already contains the monitor, the run and, when there is one, the incident.
Message behaviour
- Threading. On Slack and by email, incident-centric notifications about the same incident are grouped into threads to reduce clutter. Monitor-centric notifications are not threaded.
- Slack incident messages are edited in place. When an incident is closed, Sifflet updates the original Slack incident message instead of leaving it looking open. Monitor-centric Slack messages are never edited.
- Recovery is not emailed. A monitor recovering to passing is sent on Slack, Microsoft Teams, Google Chat and webhooks, but never by email.
- Pause notifications. You can silence a monitor until its next status change. See Monitor notifications.
Where to go next
- Notification catalog: every notification and which channels receive it.
- Notification rules: route notifications for many monitors at once.
- Monitor notifications: monitor-level overrides, pausing, best practices and monitors as code.
- Message references: Slack, Email, Microsoft Teams, Google Chat.
- Collaboration Tools: connect Slack, Email, Microsoft Teams, Google Chat, webhooks and ticketing tools.
Updated about 2 hours ago