Configure

Alert settings

Alerts tell you when something worth knowing happens without you having to go looking for it. This page covers where you configure which alerts fire and how you hear about them; for reading the alerts themselves, see the Alerts feed.

Where alerts live

Configuration lives on Settings → Alerts, on every project. What actually shows up when an alert fires — the feed of cards you scroll through, filter, and act on — is a separate screen: Alerts. This page is about the switches; that page is about reading and acting on what they produce.

Alerts are checked automatically every time a tracking run finishes — there’s nothing to trigger manually. Six rule types exist by default on every project, each with its own on/off toggle.

The six alert types

Type	Severity	Fires when…
Visibility drop	critical	Your visibility score falls sharply below its recent average.
Prompt lost	critical	Your brand disappears from a prompt it was appearing in, several runs straight.
Citation lost	critical	Your domain stops being cited on a prompt where it was cited recently.
New competitor	notice	An untracked brand keeps showing up in your AI answers.
Competitor overtake	notice	A competitor’s share of voice passes yours for the first time in a while.
Win	win	Citations gained, prompts regained, competitors overtaken — the good news, in the same feed as the rest.

Every new alert stores a versioned evidence receipt with its thresholds, scope, observed values, reference window, and confirmation observations. The current feed shows a human summary and links to the relevant prompt, platform, dashboard, or feed action; it does not render the full receipt or deep-link to an exact historical answer.

Turning rule types on and off

Each of the six rows on the Alerts settings card has its own checkbox. Switching one off stops that rule from being evaluated at all for this project — it won’t appear in the feed, and it won’t go out over Slack or email either. All six are on by default for a new project.

Delivery channels

Where an alert shows up is separate from whether it fires. Three channels exist:

In-app, Slack, and email

In-app is inherent. The moment an alert fires, it exists as a row in your Alerts feed — this channel can’t be turned off, because the feed entry is the alert.

Slack is optional and needs the Pro or Agency plan — the one delivery channel that’s plan-gated (see Plans, quotas & credits). It’s configured with a single incoming webhook URL that applies to every alert type at once — there’s no per-rule Slack toggle, just the one shared webhook.

Email is optional and covers critical alerts only — visibility drop, prompt lost, and citation lost. Notices and wins stay in-app and Slack; they don’t email.

Setting up Slack

Requires Pro or Agency

Slack delivery is included on the Pro and Agency plans. On Starter, alerts still fire and land in the in-app feed (and critical ones can still email) — they just don’t post to Slack until you upgrade.

Create a Slack incoming webhook

In Slack, set up an incoming webhook for the channel you want alerts posted to. You’ll get a URL that starts with https://hooks.slack.com/.

Paste it into Alert settings

Paste the webhook URL into the Slack field and save. The field is write-only by design — once saved, the settings screen shows only a “configured” badge and a masked placeholder, never the URL itself.

Replace or remove it any time

Click Replace to swap in a new webhook, or save the field empty to remove it. A URL that doesn’t start with https://hooks.slack.com/ is rejected before it’s saved, with an inline error explaining why.

Every alert posted to Slack carries a severity emoji, the alert title and detail, and a link straight back to the evidence in OptimizeCamp.

Email delivery

Check “Email critical alerts” to turn email on. When it’s on, critical alerts go to the earliest-added workspace owner. If there is no owner membership, delivery falls back to the earliest-added member. There’s no separate recipient list to manage.

Note

Email delivery depends on the workspace having an email-sending key configured in the environment. If it isn’t set, the checkbox still works, but the settings page tells you plainly that emails will be skipped until it’s configured — nothing fails silently.

An attempted delivery whose HTTP response fails or whose request throws is recorded against that alert as failed. A channel that was never configured is simply skipped, not counted as a failure. The integration does not currently turn a later provider-side email bounce into a failed event. Either way, the alert always still exists in your in-app feed.

Alerts

Reading, filtering and acting on the alert feed these settings control — including how to promote a new competitor to tracked.

Key takeaways

Six alert types exist per project — visibility drop, prompt lost, citation lost (critical), new competitor, overtake (notice), and win — each checked automatically after every tracking run.
Each rule type has its own on/off toggle; one project-wide email flag and one Slack webhook are shared across all six rules.
In-app delivery is always on. Slack is available on Pro and Agency. Email covers critical alerts only and selects owners first by membership age, then the first member.
The Slack webhook URL is write-only once saved — the settings screen never shows it back to you, only a configured badge.

Next step