Notifications | cside docs

What are notification configs?

Notification configs are rule-based alert configurations that let you define what triggers a notification, which domains it applies to, and where the notification is delivered. They are managed at the team level from Team Settings > Notifications.

Each config consists of three parts:

Trigger - the event type that fires the notification (e.g., a malicious script detected)
Domain scope - which domains the rule applies to (all domains or specific ones)
Destinations - where the notification is sent (email, webhook, Slack, Jira, Linear, or S3)

You can create multiple notification configs per team, each with different triggers, scopes, and destinations.

Creating a notification config

Open the dashboard and navigate to Team Settings
Select the Notifications tab
Click New Config (or Create notification config if you have none yet)
Enter a Rule Name (e.g., “Monitor PCI compliance” or “Slack alerts for threats”)
Select a trigger from the Trigger Library
Configure the domain scope - choose all domains (including future ones) or select specific domains
Add one or more destinations under “Send To”
Configure each destination’s settings in the Configuration panel
Click Save or Save & Test to create the config

Save & Test

Save & Test creates the notification config and immediately sends a test notification to all configured destinations, so you can verify everything is working. It is not offered for Outbound Connections Pending Review and CSP Policy Digest, which have no test send.

Trigger library

This page documents all 13 notification trigger types. The trigger library itself shows 12 of them when you build a notification config, because Fingerprint Export is set up from Settings > Device Intelligence instead. CSP Policy Digest only appears for teams with CSP Builder enabled, so a team without it sees 11. Some triggers deliver notifications immediately, while others aggregate events into a digest.

Delivery is a property of the rule, not of the trigger. There are four schedules: Immediate, Hourly, Daily and Weekly. Each trigger starts on a default schedule, and where a trigger supports more than one, a schedule picker appears next to it in the When panel. The Delivery column lists the default first, then the schedules that trigger accepts. The Destinations column lists which destination types the trigger can be saved with; “Any” means email, webhook, S3, Jira, and Linear.

For eligible teams, Datadog also supports immediate script threats, managed-list alerts, malicious tag managers, malicious outbound connections, and vulnerability alerts. It does not support Security Headers Changed or scheduled digests. See Datadog delivery restrictions.

Trigger	Description	Delivery	Destinations
PCI Report Available	Delivers the PCI DSS report for the scoped domains that have checkout paths configured. A weekly rule runs on Mondays and covers the previous week; a daily rule covers the previous day. Domains without checkout paths are skipped.	Weekly by default. Daily or weekly.	Email, webhook and S3
PCI Vendor Review Reminder	Sent on Thursdays when script vendors seen on your payment pages in the previous seven days still have no PCI DSS review decision. The reminder carries the number of pending vendors and the first few vendor names. Nothing is sent when no vendors are pending.	Weekly (Thursday).	Email only
Script Threat Detected	Fires when the rules engine raises a threat alert on a script, covering rulesets such as obfuscation, injected redirectors, keyloggers, crypto miners, fake checkout overlays and code reading payment fields. Any alerting ruleset that is not one of the vulnerability, managed list, tag manager or outbound connection rulesets below arrives under this trigger.	Immediate.	Any
Script Blocked by CSP	A digest of the Content Security Policy violation reports collected for the scoped domains, with the violation count per domain plus the most frequently blocked URLs and violated directives. A weekly rule runs on Mondays and covers the previous week; a daily rule covers the previous day. Nothing is sent when the window has no violations.	Weekly by default. Daily or weekly.	Email and webhook
Outbound Connections Pending Review	A digest counting the distinct outbound hostnames observed on the scoped domains that your team has not yet approved in Resources inventory. A weekly rule runs on Mondays over the previous seven days; a daily rule covers the previous day. Nothing is sent when nothing is pending.	Weekly by default. Daily or weekly. No test send.	Email and webhook
Malicious Outbound Connection	Fires when an outbound connection from one of your monitored pages reaches a hostname on cside’s managed threat list.	Immediate.	Any
CSP Policy Digest	Tells you when the Content-Security-Policy header CSP Builder recommends for a scoped domain has changed since the last check, for example because a new host appeared in traffic. A weekly rule runs on Mondays; a daily rule runs every day. Nothing is sent when the recommended policy is unchanged. Only shown for teams with CSP Builder enabled.	Weekly by default. Daily or weekly. No test send.	Email and webhook
High-risk Vulnerability	The urgent lane of vulnerability detection: fires when a finding is classified as malware, or its severity is high or critical.	Immediate.	Any
Vulnerable Script Detected	Fires when a script matches a known vulnerability from the OSV or RetireJS databases and the finding is not high risk, meaning it is neither malware nor high or critical severity. By default, findings whose weakness only affects server or build side code and whose severity is below high stay in the dashboard instead of alerting; you can turn that filter off on the rule.	Weekly by default. Immediate, daily or weekly. Daily and weekly are batched into a digest.	Any on the immediate schedule; email and webhook on daily or weekly
Managed List: Flagged	Fires when a script is served from a URL, domain, hostname or IP address on cside’s managed threat list.	Immediate.	Any
Malicious Tag Manager	Fires when a script loads a Google Tag Manager container ID on cside’s managed threat list.	Immediate.	Any
Security Headers Changed	Fires when the security headers observed on a domain’s configured checkout pages differ between two consecutive 12 hour observation windows, including a header that disappears. Only domains with checkout paths are checked, and each domain and window is reported once.	Immediate.	Any
Fingerprint Export	Writes Device Intelligence fingerprint and risk evaluation results for your team to your S3 bucket as a daily batch, in JSONL or Parquet. It accepts a Fingerprint S3 destination only, and is set up from Settings > Device Intelligence rather than from the trigger library.	Daily.	Fingerprint S3 only

Fingerprint Export

Device Intelligence fingerprint exports to S3 are configured from Settings > Device Intelligence rather than from the trigger library above, and require a plan that includes Device Intelligence. Exports are written daily to the S3 destination you configure there. See the S3 export guide for details.

Destination restrictions

Three triggers are delivered by scheduled jobs that only send email and webhooks: Outbound Connections Pending Review, CSP Policy Digest, and Vulnerable Script Detected when its schedule is daily or weekly. PCI Report Available accepts email, webhook and S3. PCI Vendor Review Reminder is email only. Saving one of these with another destination type fails with a validation error. Script Blocked by CSP is also delivered by a scheduled job that only sends email and webhooks: other destination types can still be saved on it, but they receive nothing. The other triggers use the destination types listed in the table; Datadog has the additional restrictions above.

Immediate vs. digest triggers

Immediate triggers send a notification as soon as the event is processed. Use these for security-critical events like threat detections, malicious outbound connections and high-risk vulnerabilities.

Digest triggers aggregate events and deliver them on a schedule. This prevents alert fatigue for high-frequency events like CSP blocks or routine (low and medium severity) vulnerability findings. High or critical severity vulnerabilities and malware always fire immediately under High-risk Vulnerability, regardless of how you have configured the routine Vulnerable Script Detected trigger.

Digests are only sent when there is something to report. A daily digest covers the previous day and a weekly digest is sent on Monday for the previous week, except for PCI Vendor Review Reminder, which is sent on Thursday. See the Destinations column above for which digests are limited to email and webhook.

Vulnerability notification filtering

The Noise Filter on Vulnerable Script Detected is enabled by default and affects immediate notifications for routine vulnerabilities. It can suppress notifications for findings confirmed with high confidence to affect only server or build code and not be reachable in the browser. Findings stay scored and visible in the dashboard, and remain in daily and weekly digests.

When a verdict is not yet available, a routine notification can wait for verification. The default hold is 30 minutes; unresolved findings are then released for delivery. This is a verification window, not a delivery-time guarantee. High and critical severity findings and malware use the immediate High-risk Vulnerability trigger and are never filtered by this option. Turn the filter off to receive all routine findings on the immediate schedule.

Domain scope

Each notification config can be scoped to specific domains or applied to all domains in your team:

All domains (including future domains) - the rule applies to every domain in your team, including any domains added later
Specific domains - select one or more domains from a list. The rule only triggers for events on those domains

Destinations

Destinations define where notifications are delivered. You can add multiple destinations to a single config - for example, send threat alerts to both Slack and Jira simultaneously.

Destination	Description	Setup guide
Email	Send notifications to team members or external email addresses	See below
Webhooks	HTTP POST requests with JSON, Slack, or Discord formatting	Webhook guide
S3	Store notifications in AWS S3 buckets	S3 guide
Jira	Automatically create Jira issues from alerts	Jira guide
Linear	Automatically create Linear issues from alerts	Linear guide
Datadog	Supported alert events and alert-count metrics; Enterprise and team enablement required	Datadog

Email notifications

Email is a built-in destination type. When configuring an email destination, you can:

Notify all team members (including future members) - every user on your team receives the notification
Select individual team members - choose specific users from your team
Add external email addresses - forward notifications to addresses outside your team (e.g., a ticketing system or SIEM)

You can combine these options - for example, notify all team members and also forward to your SIEM.

Integrations

Some destinations (Jira, Linear) require a team integration to be connected before they can be used as destinations:

Go to Team Settings > Integrations
Click Connect Jira or Connect Linear
Follow the OAuth authorization flow
Once connected, the destination becomes available in your notification configs

Routing alerts to Zapier

You can also route alerts through the Zapier integration to reach thousands of downstream tools. Zapier connects from Team Settings > Integrations and is used as a trigger inside Zapier, rather than added as a destination in a notification config.

Testing notifications

You can test your notification configs in two ways:

Save & Test - when creating or editing a config, click Save & Test to save the config and send a test notification to all destinations
Test existing config - from the notification config list, open a config’s menu and choose Send Test to All, or pick a single destination under Send test to

Test notifications are clearly marked so your team knows no action is required. Outbound Connections Pending Review and CSP Policy Digest have no test send, so neither option appears for them.

Managing notification configs

All notification configs for your team are listed under Team Settings > Notifications. From there you can:

Create new configs with the New Config button
Edit existing configs to change triggers, domains, or destinations
Delete configs you no longer need
Enable or disable configs without deleting them

All changes are recorded in your team’s audit logs.