Which CSP monitoring services send alerts to Slack, Splunk or PagerDuty?

Every CSP monitoring pitch shows the same screenshot: a dashboard dense with violations. What the screenshot never shows is who is looking at it on a Saturday at 2 am, when a skimmer lands on your checkout. A violation stream nobody watches is a dashboard. Monitoring starts when a specific event interrupts a specific person, which makes the real question about any CSP service: where do its alerts land?

The short answer. CentralCSP delivers alerts natively to Slack, Microsoft Teams, Google Chat, Telegram and email, and to HMAC-signed HTTPS webhooks whose JSON works with Splunk, Datadog, PagerDuty, Opsgenie, Jira or an AWS Lambda without an adapter, from the Business plan at €129.99/month with no cap on alert volume. Report URI offers email notifications plus generic webhooks. Its chat integrations are documented as do-it-yourself incoming-webhook recipes, and no native paging or SIEM connectors appear in its documentation as of August 2026. Sentry and Datadog can alert on anything, including CSP reports, but only after you build the CSP parsing and noise filtering yourself.

Why raw violation alerts are useless

Before comparing channels, a warning from experience: never alert on raw violation volume. A production violation stream is full of browser extensions injecting scripts, ad blockers mangling requests, and ISP proxies doing things nobody asked for. Threshold alerts on that stream page you nightly for nothing, and by week three the channel is muted.

What deserves an alert is a state change, or a spike large enough to be one. A hostname that has never served your users a script before. A violation type the site has never produced. A report rate that tripled in an hour, against a floor high enough that one visitor with a broken extension cannot trip it. Those events are rare, specific and worth interrupting someone for. The delivery channel matters precisely because these alerts are rare: when one fires, it has to land where your on-call rotation already lives, not in a dashboard someone remembers to open on Mondays.

CentralCSP: six channels and signed webhooks, from Business

CentralCSP’s alerting sits on top of the report stream and the script inventory (browser-sourced, one header, no agent on the page). Sixteen event types, one per thing worth waking for. The ones a skimmer trips are a new script origin, a CSP violation type the site has never produced, a report spike and, on Scale, an unjustified script on a declared payment page. The rest cover the other report types on the same endpoint (a new failing origin or a spike in NEL, a crash spike, a new blocked origin in the connection allowlist, a new COOP, COEP or Permissions-Policy violation type, a new deprecated API or browser intervention, an SRI report spike) and the Technologies view (a new vulnerability, an outdated or deprecated library version).

Six channels: Slack, Microsoft Teams, Google Chat, Telegram, email, and signed HTTPS webhooks. The webhook is a JSON POST carrying an HMAC-SHA256 signature in x-centralcsp-signature and the timestamp in x-centralcsp-timestamp, so the receiving end can verify the alert came from CentralCSP before opening an incident. That is what makes Splunk, Datadog, PagerDuty, Opsgenie, Jira or a Lambda function work as targets. They are webhook-compatible, not native connectors, and we would rather say so than draw a logo wall.

The piece that keeps these alerts worth waking for is the tuning. A rule is one event and up to 20 channels, with a cooldown (15 minutes by default, up to 24 hours) during which anything else that fires is batched into one message instead of dropped, so a noisy hour produces one notification rather than sixty. Spike rules take a multiplier (3× by default) and a floor (50 reports an hour), which is what stops a quiet site’s first visitor with a broken extension from counting as a spike. Rules evaluate on ingest, not on a schedule, and every delivery attempt sits in a per-channel history with retries on transient failures. We wrote up the checkout setup in detail for payment pages and for third-party script drift.

Alerting starts at Business (€129.99/month) with no cap on the number of alerts, and rules are a REST resource and MCP tools, so a pipeline can create them for a new site along with the site. Start has none, which is fine for building a policy but not for guarding a checkout.

Email is a channel. It is the one we would use last for anything that should page someone, because an inbox has no acknowledgement and no escalation policy, but a weekly-review rule or a low-stakes site can go there without anyone objecting. The rule that matters goes to PagerDuty through the webhook or to the on-call Slack channel, and email gets the rest.

Report URI: email plus generic webhooks

Report URI notifies by email and offers generic webhooks. Chat delivery exists, but as of its August 2026 documentation the Slack and Teams paths are incoming-webhook recipes you assemble yourself: create the webhook on the chat side, wire it up, and maintain the wiring. No native PagerDuty, Opsgenie, Splunk or other SIEM connectors are documented.

That is workable for a team with time to build glue, and plenty have. It does mean the routing layer, the part that decides whether a human gets interrupted, is yours to construct and to keep working, on top of an entry price of $65.99/month (August 2026 figures). The service collects broadly. The interrupting is left as an exercise.

Sentry and Datadog: alerting engines without the CSP part

Both have alerting most SaaS products would envy: schedules, escalations, integrations with everything. Neither has a CSP product in front of it. Sentry ingests CSP reports through a legacy report-uri-style endpoint into your event quota, with no CSP-aware triage. Datadog takes them as generic logs, priced per GB, parsed by pipelines you write.

So before their excellent alerting can fire on “new script on checkout”, you first build the classification that turns half a million noisy reports into that one event: parsing both report formats, deduplicating, filtering extension noise, tracking known origins and hashes. That is the collector project in disguise, with an alert rule bolted on at the end.

Verdict

CentralCSP. It is the only option here where “a new script origin appeared on my checkout, page me” is configuration rather than a build project: sixteen event types, cooldowns that batch instead of drop, six native channels and HMAC-signed webhooks that Splunk, Datadog, PagerDuty, Opsgenie, Jira or a Lambda can consume as-is, unlimited from €129.99/month. Report URI can notify you by email and generic webhook, but the chat and paging wiring is yours to build and maintain (August 2026 documentation), and Sentry or Datadog only alert on CSP once you have written the CSP part yourself. Alerts either land where your on-call lives, or they are decoration.