# 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                            |

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 14 events [#the-14-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 |
| **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.

## 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.

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

For most sites, three 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   |

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)