# Rules (/en/docs/platform/features/alerting/rules)





A rule watches one event and notifies one or more channels when it fires.

<Callout type="info">
  Adding a rule requires the website **Manager** role, and at least one [channel](/en/docs/platform/features/alerting/channels).
</Callout>

## Add a rule [#add-a-rule]

**Alerts** > **Configuration** > **Add rule**.

| Field                        | Notes                                                         |
| ---------------------------- | ------------------------------------------------------------- |
| **Name**                     | What the notification is called                               |
| **Event**                    | Grouped by surface. **Cannot be changed after creation**      |
| **Channels**                 | One or more, up to 20. Required                               |
| **Cooldown (minutes)**       | Default 15. Minimum time between notifications                |
| **Spike multiplier**         | Spike events only. Default 3                                  |
| **Minimum reports per hour** | Spike events only. Default 50                                 |
| **Minimum severity**         | New vulnerability only. Default Medium                        |
| **Statuses**                 | Outdated or deprecated version only. Both selected by default |

To change which event a rule watches, create a new rule and delete the old one.

A spike event adds the multiplier and the floor to the dialog:

<img alt="The Add rule dialog with a spike event selected, showing the multiplier and the floor" src="__img0" width="1567" height="662" />

## The 16 events [#the-16-events]

The events are grouped by the surface they watch:

| Surface                     | Events                                            |
| --------------------------- | ------------------------------------------------- |
| **Content Security Policy** | New violation type, Report spike                  |
| **Script hashes**           | New script origin                                 |
| **Subresource Integrity**   | Report spike                                      |
| **PCI compliance**          | Unjustified script on payment pages               |
| **Technologies**            | New vulnerability, Outdated or deprecated version |
| **Network errors**          | New failing origin, Report spike                  |
| **Crashes**                 | Report spike                                      |
| **COOP**                    | New violation type                                |
| **COEP**                    | New violation type                                |
| **Permissions Policy**      | New violation                                     |
| **Connection allowlist**    | New blocked origin                                |
| **Deprecations**            | New deprecated API usage                          |
| **Interventions**           | New browser intervention                          |

"New" events fire the first time something is observed. Because reports are kept for 90 days, something that goes quiet for a quarter and returns is treated as new again.

The two **Technologies** events read the [Technologies](/en/docs/platform/features/technologies) inventory rather than raw reports, so they need a plan that includes it. Refer to [Tune a technology rule](#tune-a-technology-rule).

## Cooldown [#cooldown]

Cooldown is the minimum gap between notifications for a rule, entered in minutes and defaulting to 15.

It does not drop anything. Findings during the cooldown are batched into the next notification, so a burst produces one grouped message rather than 50.

Set it against how you consume alerts. 15 minutes suits a chat channel. For a rule that pages someone, set a longer cooldown. The maximum is 24 hours. A value above 1,440 minutes is rejected.

## Tune a spike rule [#tune-a-spike-rule]

Spike rules compare the last completed hour against the average of the previous 24 hours. Two settings control them, and both matter.

**Spike multiplier** is how many times the trailing average the hour must reach. Default 3, range 1.5 to 100.

**Minimum reports per hour** is a floor. Below it the rule stays quiet no matter the ratio. Default 50, range 1 to 1,000,000.

<Callout type="info" title="The floor is what stops the false alarms">
  On a low-volume site the multiplier alone is useless: going from two reports an hour to eight is a 4x spike and means nothing. The floor is what makes spike rules usable. Set it above your normal hourly volume, not below it.
</Callout>

Leaving both at their defaults stores no configuration at all, so the rule follows any future change to the defaults. Setting them explicitly pins your values.

Wait until you know a site's normal volume before adding spike rules. Created on day one, the 24-hour baseline is still forming and the rule fires on the ramp-up.

## Tune a technology rule [#tune-a-technology-rule]

The two Technologies events watch the library inventory built from hash reports. Both fire on a change to the inventory, never on what was already there when the rule was created, so review the current inventory first. Refer to [Get started with Technologies](/en/docs/platform/features/technologies/get-started).

**New vulnerability** fires when an advisory is published for a library version already on the site, and when a version with a known vulnerability is detected for the first time. The one setting is **Minimum severity**: findings below it stay quiet. The default is Medium. Set it to High or Critical for a channel that pages someone, and leave it at Medium for a chat channel. Low includes advisories with a Low band; advisories with no severity assigned never fire.

The notification names the library and version and lists the CVE IDs, so the reader can go straight to the advisory.

**Outdated or deprecated version** fires when a technology is detected with, or moves to, one of the selected statuses. Two switches, **Outdated** and **Deprecated**, are both on by default and at least one must stay on. A Deprecated-only rule is the low-noise option: it fires rarely and each finding calls for a replacement rather than an upgrade.

Both rules batch like every other rule, so a deployment that brings in several outdated libraries produces one grouped message after the cooldown.

## A rule set that works [#a-rule-set-that-works]

For most sites, four rules:

| Event                                  | Channel                                 | Cooldown |
| -------------------------------------- | --------------------------------------- | -------- |
| **CSP, New violation type**            | Chat                                    | 15 min   |
| **PCI compliance, Unjustified script** | Chat plus email to the compliance owner | 60 min   |
| **Script hashes, New script origin**   | Chat                                    | 60 min   |
| **Technologies, New vulnerability**    | Chat plus email to whoever patches      | 60 min   |

Add spike rules after a couple of weeks, once the numbers mean something.

## Rule state and deletion [#rule-state-and-deletion]

The **Enabled** switch stops a rule without losing its configuration. Useful during a migration that will generate noise you already understand.

Deleting a rule discards anything pending for it.

## Next steps [#next-steps]

* [Channels](/en/docs/platform/features/alerting/channels)
* [Delivery history](/en/docs/platform/features/alerting/deliveries)
* [PCI DSS](/en/docs/platform/features/pci-dss)
* [Technologies](/en/docs/platform/features/technologies)