Alerts

The alerts engine watches every completed scan and snapshot for movement worth knowing about. When a rule fires, you get a notification in-app, an email, and (if configured) a webhook to Slack or any generic endpoint.

What gets watched

Alerts run on snapshot diffs, not raw scans. That means we don't notify you on every individual response — we wait until the aggregate moves enough to be meaningful.

Current rule set (with cross-platform corroboration):

Rule	Fires when
Mention rate drop	Your mention rate fell ≥10% in this window vs the previous one, AND the drop appears on at least 2 of the 4 platforms
Competitor surge	A competitor's mention rate rose ≥10% in the same window, on ≥2 platforms
Sentiment swing	Sentiment mix shifted toward negative ≥15 percentage points
New competitor detected	An untracked brand was named in ≥5 responses over the last 14 days, on ≥2 platforms
Tier 1 source gap	A high-authority domain (DR > 70) is citing competitors but not you for ≥5 queries

The cross-platform corroboration matters: a single LLM having a bad day shouldn't fire an alert. Two LLMs both moving in the same direction is signal.

Repeats have to earn themselves

Every rule has a cooldown, but a cooldown is only a timer — and a timer will happily re-send an alert whose underlying situation hasn't changed at all. So a repeat of an alert you've already had must also clear a materiality bar, measured against the value we reported last time:

Rule	Repeats when
New competitor detected	The mention count has grown by at least half again
Competitor surge	The mention count has grown by at least half again
Mention rate drop	Your rate has moved ≥5 points in either direction
Monthly spend threshold	Always (once per calendar month)
API key problem	Always (a broken key is an outage — we re-warn daily until fixed)

The rate rule is deliberately two-directional: if we told you about a drop to 40%, you recovered to 60%, and you've now fallen to 45%, that's a genuine new drop even though 45% isn't below 40%.

Suppressing a repeat does not restart the cooldown, so a real move the next day still reaches you immediately.

Discovered competitors have an end state

"New competitor detected" is about a name that isn't in your tracked brands yet. You resolve it on Brands → Discovered, and the alert links straight to the row:

Track — creates the competitor brand and counts it in share of voice from the next scan onward. (Existing mentions aren't backfilled.)
Dismiss — permanently stops surfacing that name, including in future scans that mention it again. Reversible from Show dismissed.

Until you do one or the other, the candidate stays live and can alert again if its mention count grows materially.

Delivery channels

Each alert can deliver to multiple channels — they're all wired through one notification abstraction with per-user, per-channel preferences.

In-app

Every alert appears in the notification center (bell icon, top-right) with a clickable link to the relevant detail page. Unread count badge persists across sessions until you click "Mark all read."

Email

Email is the only channel that batches, and the split is "does this need action within the hour?":

Sent immediately	Batched into one daily email
API key problem, monthly spend threshold, weekly digest, app updates	Competitor surge, new competitor detected, mention rate drop

Batched alerts are collected and sent as a single email at 12:00 UTC listing each update with its own link. If only one thing happened that day, it arrives as an ordinary single email rather than a one-item digest.

Nothing is lost either way: the in-app list always receives every alert the moment it fires, whatever your email settings say.

Webhook (Slack + generic)

Configure a webhook URL in Settings → Notifications → Webhook delivery. Every notification fires a POST request with a JSON payload. You can use:

Slack incoming webhook — https://hooks.slack.com/services/.... We format the payload to render as a Slack Block Kit card.
Generic JSON endpoint — any URL accepting POST application/json. Useful for piping into your own data warehouse or routing through Zapier/n8n.

See Webhook delivery for the full payload schema.

Configuring alerts

In Settings → Notifications you can:

Set the email cadence per rule — Immediate, Daily, or Off. Daily is offered only for the market-movement rules; an out-of-credits warning is deliberately not something you can put on a 24-hour delay.
Toggle in-app per rule — on or off. There's no cadence here: the notification centre is a feed, and it always gets every item as it happens.
Configure one webhook URL for all notifications (see below)

Muting a rule for one specific competitor isn't supported — to stop hearing about a particular discovered name, dismiss it on Brands → Discovered.

We deliberately keep thresholds non-customizable in v1 — too many knobs leads to thresholds drifting until alerts mean nothing. If you have a strong opinion on a different threshold, send feedback; we tune the defaults based on aggregate signal.

When alerts don't fire

First two windows of data — we need at least two consecutive snapshots to compute a diff. Brand-new workspaces won't fire alerts on their first weekly scan.
Too few scans — if the window has fewer than 10 scans, percent-change thresholds become noisy and we suppress. You'll see a quiet banner explaining this on /insights.
All four platforms agree it's flat — if no platform moved by ≥5%, no alert fires regardless of aggregate.

What's not in the alerts engine yet

Custom rules — "alert me when competitor X surges specifically." On the roadmap as Pro-tier feature.
Real-time alerts — alerts run after snapshot materialization (typically within minutes of the last scan landing). Sub-minute paging isn't supported.
Anomaly detection beyond rules — we don't run a model to find "unusual things." All alerts are deterministic rule-driven, so when one fires you know exactly why.