Rule Notifications
The Notifications tab decides what happens to the detections a rule raises. Settings that describe the rule as a whole, such as what its detections contain, are on the Settings tab instead.
The tab is a list of notifications. A rule can have any number of notifications and each one is delivered independently. A rule that both writes detections to a feed for later analysis and emails a few people about them has two notifications, not one.
| Column | Description |
|---|---|
| Enabled | Whether this notification is delivered. |
| Type | Stream or Email. |
| Destination | The feed or email address that detections go to. |
| Limit | Whether the number of notifications is limited. |
| Max | The limit, where one is set. |
Note
Everything on this page applies to Reports as well, except that a report delivers a file rather than a detection. The differences are covered in Report Delivery.
Stream Destinations
A Stream notification writes detections into a
Feed
Feed
detection:1
XML Schema
XML Schema
| Field | Description |
|---|---|
| Destination Feed | The feed the detections are written to. Use Set Default to use the feed configured for the system. |
| Use Source Feed If Possible | Writes detections to the feed the source data came from rather than to the destination feed. |
Use Source Feed If Possible is useful for a streaming rule that runs across many feeds and whose detections are best kept alongside the data that produced them.
Note
See Also
Email Destinations
An Email notification sends each detection to people as an email.
| Field | Description |
|---|---|
| To | Recipient addresses. |
| Cc | Addresses to copy. |
| Bcc | Addresses to copy without other recipients seeing. |
| Email Subject Template | A template for the subject line. |
| Email Body Template | A template for the body. |
Each field accepts more than one address.
Note
Templates
The subject and body are Jinja templates rather than fixed text, so that each email can describe the detection that triggered it.
The values from the detection are put into the template context before the template is rendered, so {{ detectTime }} renders when the detection happened and values.SourceIp renders the value of the query’s SourceIp column.
If the rendered body looks like HTML it is sent as an HTML email, otherwise it is sent as plain text.
See Also
Testing
Two buttons let you check a template without waiting for a real detection.
- Test Template renders the template against an example detection and shows you the result, including any errors in the template.
- Send Test Email sends that example detection to the configured recipients, which also proves the SMTP configuration works.
Limiting Notifications
A rule that suddenly matches far more data than expected can send a very large number of emails. The limit settings exist to bound that.
| Field | Description |
|---|---|
| Limit Notifications | Whether a limit applies. |
| Maximum Notifications | How many notifications may be sent before this one stops. |
| Resume Notifications After | How long to wait before allowing notifications again. |
Once Maximum Notifications have been sent the notification switches itself off and nothing further is delivered through it. It comes back on when Resume Notifications After has elapsed since the last notification was sent, at which point the count starts again from zero.
Warning
Detections suppressed by a limit are discarded, not queued. A rule that hits its limit will not deliver the detections it raised while switched off, even after it resumes.
Where the aim is to avoid being told the same thing repeatedly rather than to bound the volume, Duplicate Management is usually the better tool, because it suppresses repeats of a detection you have already seen while still delivering new ones.
The count is held per notification and is not persisted, so restarting the node resets it.