PubSentry watches your traffic continuously, but you don't have to. Alerts surface the three events that actually matter to a publisher — a sudden spike in invalid traffic, an ad-policy mistake that risks your account, and a coordinated attack — and push them to where you already work (Slack or a webhook), plus an in-dashboard notifications feed. This page explains exactly what fires, when, and how delivery is kept safe.
The three alert triggers
A site can have any number of alert rules. Each rule has a trigger, an optional threshold, and a channel. There are exactly three triggers, and they map to the failures a publisher cares about most:
ivt_spike — invalid traffic jumped
Fires when your invalid-traffic rate in the last hour rises sharply versus its 24-hour baseline (the hour before, back through the prior 25 hours). The threshold is a relative increase — 0.5 (the default) means "fire when this hour's invalid rate is at least 50% above baseline." If there is no meaningful baseline yet, it falls back to firing when the current hour crosses a 10% invalid floor.
There's a deliberate floor on noise: a spike is ignored if the current hour saw fewer than 20 events, so a quiet site doesn't page you over three bad visitors. This is the alert that catches a botnet finding your site, a bad traffic-source deal, or a referral-spam wave.
policy_violation — a fresh ad-policy mistake
Fires when distinct high/critical ad-policy findings surface in the last hour — by default, one is enough. PubSentry's tag scans your pages for placement and content issues that violate ad-network policy (the kind of setup mistake that gets accounts suspended). When a new high-severity finding appears, this alert tells you to review the Ad Policy scorecard before it risks your AdSense or ad-network standing.
attack — a coordinated cluster is live
Fires when the AI Security Engineer's sweep identifies an active coordinated cluster whose invalid rate exceeds a floor (default 0.5, i.e. 50%). These are correlated entities — a shared ASN, a fingerprint cohort, a referral ring — acting together. The alert names the top offending entities and points you at the Attacks screen, where the Engineer already has counter-rules drafted for you to review.
How and when alerts evaluate
Alerts are evaluated on a schedule by the same sweep that powers the AI Security Engineer (every ~15 minutes in production). On each tick the scheduler:
- Runs the agent sweep over every site with traffic in the last 24 hours, refreshing snapshots, findings, and the active attack clusters.
- Evaluates each site's alert rules against ClickHouse —
ivt_spikeandpolicy_violationquery the event stream directly;attackreads the clusters the sweep just refreshed. - Delivers any fired events to their channel and records them in the notifications feed.
A per-rule cooldown (one hour by default) stops the same alert re-firing on every tick during a sustained spike. You get told once, not every 15 minutes for an hour.
Because evaluation runs server-side over already-ingested data, nothing about alerting changes the install. It's the same single async tag every site uses:
<script async src="https://pubsentry.com/t.js" data-site="st_xxxx"></script>Channels: Slack and webhooks
Each rule delivers to one channel:
- Slack — paste an incoming-webhook URL. PubSentry posts a formatted message (
PubSentry — <the alert message>) into the channel that webhook targets. - Webhook — any HTTPS endpoint of yours. PubSentry POSTs a JSON body containing the
rule_id,site_id,trigger, human-readablemessage, and the numericvaluethat fired it. Wire it into PagerDuty, Opsgenie, a Lambda, or your own incident tooling.
Delivery is hardened on purpose
Two safeguards matter here. First, an SSRF guard: a publisher-supplied channel URL is rejected unless it is http/https and resolves to a public address. Loopback, link-local (including the 169.254.169.254 cloud-metadata endpoint), and private ranges are blocked — a webhook target can never be turned into a probe of internal infrastructure. Second, every delivery fetch is time-bounded (a 5-second abort), so a slow or hanging endpoint never stalls the scheduler. Delivery failures are recorded, not retried into a loop, and they never block other alerts.
Test before you trust it
You don't have to wait for a real spike to know your wiring works. Two tools let you validate a rule up front:
- Test-fire — sends a sample alert ("your channel is wired up correctly") through the exact same delivery path, SSRF guard included. If it lands in Slack, your channel is good. If it doesn't, you find out now instead of during an incident.
- Backtest — for
ivt_spike, replays your last 7 days of real hourly traffic against a chosen threshold and reports how many times the rule would have fired. This lets you tune the threshold against your own data: too sensitive and it fires on normal variance; too loose and it misses real spikes. The backtest uses the identical baseline math the live evaluator uses, so what you see is what you'll get.
The in-dashboard notifications feed
Every alert that fires is also written to the notifications feed — the header bell in the dashboard — so the record exists even if a channel delivery fails (failures are flagged in the entry). Notifications are the actionable subset of the Engineer's worklog: fired alerts, detected attacks, and pending recommendations. Each one deep-links to the screen that resolves it — an attack notification jumps to Attacks, a policy_violation to the Ad Policy scorecard, an ivt_spike to your alert rules. The bell is the single place to see "what needs my attention," with the path to fix it one click away.
What's not here yet
Alerts deliver outbound to Slack and webhooks today, and that path is live and hardened. A few related capabilities are honestly roadmap, not shipped:
- Email notifications (coming) — alerting over email needs an SMTP/SES channel, which isn't wired up yet. Use Slack or a webhook for now.
- A stable public API and inbound webhooks (coming) — the
/v1/*endpoints behind the dashboard are session-scoped to your account and may change; they are not a documented integration surface. If you want to manage alert rules programmatically across many sites, tell us what you're building so we can scope it honestly.
A note on signal quality
Alerts are only as trustworthy as the verdicts behind them, and PubSentry's first principle is FPR = 0 — never block a real human. The same conservative engine that decides what to block decides what counts toward an ivt_spike, so a spike alert reflects traffic we're genuinely confident is invalid, not a jittery heuristic. We catch obvious and general invalid traffic at near-100% recall with zero false positives; sophisticated residential-IP mimicry is only partially caught today and closes as the reputation network and ML moat grow. We don't page you on noise, and we never claim to see what we can't.