Your site changed. Your team already knows.

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.

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.

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.

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.

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.

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.

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.

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.

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.