﻿---
title: "CSP violation & script change alerts in Slack, Teams"
description: "CSP and script-change alerts in Slack, Teams, Telegram, email or a signed webhook, the moment a report lands. Detection and alerting for PCI DSS 11.6.1."
url: "https://centralcsp.com/en/platform/alerting/"
lang: "en"
---

Alerts

# Your site changed. Your team already knows.

Add a rule once. When a real visitor's browser reports the change, the message is already in the channel that owns that page.

[Start free trial](https://app.centralcsp.com) [See what we monitor](https://centralcsp.com/en/platform/monitoring/)

-   Fires on ingest
    
    Not a nightly sweep
    
-   Six destinations
    
    Chat, email or webhook
    
-   Routed per site
    
    And per team
    
-   No agent
    
    One response header
    

[Set up your first alert rule](https://centralcsp.com/en/docs/platform/features/alerting/get-started) takes about ten minutes.

Triggers

## What's worth interrupting someone for.

An alert rule is an event a browser reported, a page scope, one or more channels and a cooldown. New origin, script change detected by hash, payment-page tamper detection: the source is always the browser's own report, never a crawler or an injected agent.

-   ### A new origin appears
    
    A script loaded from a host you have never seen. Magecart and formjacking skimmers open exactly here: a new host, then a card form quietly reporting to it.
    
-   ### A script changed
    
    A file you execute no longer matches yesterday's hash. Your build did it, or somebody else did.
    
-   ### Something touched a payment page
    
    Card-data pages get their own rules, because [PCI DSS 11.6.1 asks you to alert on changes to them](https://centralcsp.com/en/platform/pci-dss/).
    
-   ### A known CVE turns up
    
    A library you load has a published advisory. You hear it with the version and the CVE id. [See how the script inventory finds them](https://centralcsp.com/en/platform/supply-chain/).
    
-   ### Reports spike
    
    Violations jumped after the 4pm deploy. Something broke at scale, and the browsers said so first.
    
-   ### A silent signal wakes up
    
    A directive that reported nothing all quarter started talking. Worth a look before it is worth an incident.
    

These six are the ones worth interrupting someone for. The full event catalogue is larger: [every event a rule can watch, with scope and cooldown](https://centralcsp.com/en/docs/platform/features/alerting/rules).

Channels

## This is what an alert looks like.

The same rule, reaching three teams where they already work. Every rule picks its own destination, so a checkout incident and a marketing-site warning never land in the same thread.

-   
-   
-   

Every destination a rule can reach

-   Slack
-   Microsoft Teams
-   Google Chat
-   Telegram
-   Email
-   Webhooks

Setup

## Configured once, then it runs without you

Channels, rules and delivery history live on one screen. Connect a destination, point rules at it, then check afterwards what actually went out.

### Every rule reaches the team that owns the page

Add a channel, Slack, Teams, Google Chat, Telegram, email or a webhook, then choose which events reach it. A new origin on checkout goes to the payments team, a broken directive on the blog goes to whoever ships the blog.

[Start free trial](https://app.centralcsp.com)

![The alerting screen: the connected channels on one side, and the rules deciding which events reach which channel.](https://centralcsp.com/assets/cta-alerts-D_o4f2qB.webp)

### One message, not four hundred

Reports arrive deduped and grouped, and every rule takes a cooldown, so a bad deploy interrupts someone once.

### Delivery history per channel

Every attempt is recorded with its status and the reason it failed, and transient failures are retried. No guessing whether a message went out.

### API and MCP

Rules are a REST resource, and the same operations run over the built-in MCP server. Onboarding a hundred sites is a loop.

Further reading

## Set up your first rule

Every event a rule can watch, every channel it can reach, and what happens when a delivery fails.

-   [Set up your first alert rule](https://centralcsp.com/en/docs/platform/features/alerting/get-started)
-   [Events, scope and cooldowns](https://centralcsp.com/en/docs/platform/features/alerting/rules)
-   [Every alert channel and the URL it needs](https://centralcsp.com/en/docs/platform/features/alerting/channels)
-   [Verify a signed webhook](https://centralcsp.com/en/docs/platform/features/alerting/channels/webhook)
-   [Delivery history and retry behaviour](https://centralcsp.com/en/docs/platform/features/alerting/deliveries)
-   [How to detect a Magecart skimmer client-side](https://centralcsp.com/en/blog/magecart-formjacking-detection)

FAQ

## Frequently asked questions

Channels, speed, noise and compliance, answered.

### Can I get CSP violation alerts in Slack?

Yes, and in Microsoft Teams, Google Chat, Telegram, email or any webhook you host. Connect the channel once, then point rules at it. A rule can post to more than one channel, and two rules on the same site can reach different teams.

### Why alert instead of just blocking the script?

Magecart and formjacking skimmers are the reason. Blocking is the Content Security Policy's job, and you should have one. What a policy cannot do is tell a good change from a bad one inside a vendor you already approved, which is how British Airways was breached. The policy closes the doors; alerts tell you when something moved in a room you already let someone into.

### How fast does an alert arrive?

Rules are evaluated as reports arrive, and browsers send reports shortly after a page loads. In practice you hear about a new script on the next page view that loads it, not on a nightly sweep. For comparison, Cloudflare Page Shield batches its new-resource alerts daily and its code-change alerts up to every 24 hours.

### Won't I drown in CSP noise?

That is the usual failure mode, and it comes from alerting on raw reports. Yours arrive deduped, grouped by directive and origin, and with browser-extension false positives already flagged. You can also scope any rule to the pages that matter, so the checkout and the blog never share the same rule. On top of all that, every rule takes a cooldown: tell it how long to stay quiet after it fires and a bad deploy produces one message, not four hundred.

### What happens if Slack or my webhook is down?

The delivery is retried, and every attempt is recorded in the delivery history with its channel, its status and the reason it failed. Transient failures, such as a timeout or a 5xx from your endpoint, are retried. Permanent ones are not: a webhook URL that has been revoked, a Slack channel that no longer exists, or a 4xx that says the request itself is wrong will not succeed on a second attempt, so the history shows it as failed rather than retrying forever. You read the outcome per rule, per channel, rather than guessing whether a message was ever sent.

### Does this satisfy PCI DSS 11.6.1?

It is the detection and alerting half of it. Requirement 11.6.1 asks for a change- and tamper-detection mechanism that alerts personnel to unauthorized modification of payment pages and their HTTP headers, as received by the consumer browser, at least once every seven days. CentralCSP's reports come from the consumer browser and its rules fire on arrival. Pair it with the script inventory for 6.4.3 and export both as evidence.

### Do I need an agent or a script on the page?

No. Alerting rides the same response header as monitoring. Browsers generate the reports themselves, so there is nothing to install, nothing to keep updated, and no third-party script added to the pages you are trying to protect.

### Do alerts work while my CSP is still in Report-Only?

Yes, and that is usually where you want them. Rules run on the reports a browser sends, not on the blocks it performs, and Content-Security-Policy-Report-Only sends exactly the same violation reports while blocking nothing. So you can watch for a new origin or a changed script through the whole report-only rollout, before you enforce anything.

### Can I create alert rules over the API?

Yes. Rules are a REST resource, and the same operations are available over the built-in MCP server, so onboarding a hundred sites is a loop rather than an afternoon. An API key acts as the person who created it, with that person's roles, and revoking it cuts the integration off immediately.

## Set one rule today. Forget about it until it matters.

Add the header, connect a channel, pick the change worth a message. 14-day free trial, no agent to deploy.

[Start free trial](https://app.centralcsp.com) [Check your reporting setup](https://centralcsp.com/en/tools/reporting-api/)

---

Available in: [en](https://centralcsp.com/en/platform/alerting/), [fr](https://centralcsp.com/fr/platform/alerting/)
