Notifications

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:

1. Trigger - the event type that fires the notification (e.g., a malicious script detected)
2. Domain scope - which domains the rule applies to (all domains or specific ones)
3. 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

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

Trigger library

This page documents all 12 notification trigger types. The trigger library itself shows 11 of them when you build a notification config, because Fingerprint Export is set up from Settings > Device Intelligence instead. Two of those 11 only appear for teams with the Resources inventory feature, so a team without it sees 9. 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.

Trigger	Description	Delivery
PCI Report	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.
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 destinations 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.
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.
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. Requires the Resources inventory feature.	Weekly by default. Daily or weekly. Email and webhook destinations only.
Malicious Outbound Connection	Fires when an outbound connection from one of your monitored pages reaches a hostname on cside’s managed threat list. Requires the Resources inventory feature.	Immediate.
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.
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.
Managed Flagged	Fires when a script is served from a URL, domain, hostname or IP address on cside’s managed threat list.	Immediate.
Malicious Tag Manager	Fires when a script loads a Google Tag Manager container ID on cside’s managed threat list.	Immediate.
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.
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.

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.

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

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:

1. Go to Team Settings > Integrations
2. Click Connect next to the service (Jira or Linear)
3. Follow the OAuth authorization flow
4. Once connected, the destination becomes available in your notification configs

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, trigger a test for any saved config

Test notifications are clearly marked so your team knows no action is required.

Managing notification configs

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

• Create new configs with the Create Notification 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.