# Overview (/en/docs/platform/features/alerting)







Alerting watches the reports arriving for a website and notifies you when something matches a rule you set. 16 events are available, across CSP, script hashes, integrity, network errors, crashes, browser policies, PCI DSS compliance, and the library inventory built by [Technologies](/en/docs/platform/features/technologies).

You configure alerting per website under **Alerts**, which has two tabs: **Configuration** for channels and rules, **Delivery history** for what was sent.

<Callout type="info">
  Alerting requires a plan that includes it, and the website **Manager** role to change anything. Viewers and analysts see the configuration read-only.
</Callout>

## Channels first, then rules [#channels-first-then-rules]

A **channel** is a destination. Each one can be tested on its own, and switches itself off after five consecutive failures.

Each channel carries its destination, a switch, and a test control:

<img alt="The channels list, each channel with its destination, an enabled switch, and a test control" src="__img0" width="1495" height="505" />

A **rule** is what to watch and where to send it. Rules cannot exist without a channel, so create one first.

Each rule shows the event it watches and the channels it notifies:

<img alt="The rules list, each rule showing the event it watches and the channels it notifies" src="__img1" width="1456" height="824" />

1. [Add a channel](/en/docs/platform/features/alerting/channels) and send a test.
2. [Add a rule](/en/docs/platform/features/alerting/rules) pointing at it.
3. Check [Delivery history](/en/docs/platform/features/alerting/deliveries) once something fires.

## Two things to know before you start [#two-things-to-know-before-you-start]

**Rules only look forward.** The detection sweep runs every minute over reports that just arrived. A new rule never replays history, so it does not tell you about anything that happened before you created it. Use the report pages for that.

**Cooldown batches rather than drops.** Findings that occur during a cooldown are collected and sent in the next notification. A noisy hour produces one grouped message rather than silence or a flood.

## Which events to start with [#which-events-to-start-with]

You do not need many rules. Three cover most of the value:

* **`New violation type` on CSP:** Something started loading that never loaded before. On a stable site this is the highest signal event available.
* **`Unjustified script on payment pages`:** Directly tied to PCI DSS 6.4.3, and the one your compliance lead cares about.
* **`New script origin` on script hashes:** A new party is now executing code on your pages.
* **`New vulnerability` on Technologies:** A library your visitors load just gained a published CVE, on plans that include Technologies.

Spike events are useful once you know your normal volume. Adding them on day one produces noise, because the baseline is still forming.

## Usage alerts are separate [#usage-alerts-are-separate]

Notifications about approaching your report quota are not part of this system. They are configured under **Settings** > **Usage** at the workspace level and per website, and they only go by email. For more information, refer to [Usage alerts](/en/docs/platform/features/alerting/usage-alerts).

## Next steps [#next-steps]

* [Get started](/en/docs/platform/features/alerting/get-started)
* [Channels](/en/docs/platform/features/alerting/channels)
* [Rules](/en/docs/platform/features/alerting/rules)