Alerts & alert history

An alert is raised when a scan result crosses a threshold defined by your policies.

Policies are attached to campaigns, so only scans that belong to a campaign can raise alerts: scans queued by a campaign run, and scans submitted through the API with a campaign_id — on POST /api/v1/scans and POST /api/v1/scans/bulk alike. A scan submitted without one is still checked and tagged, but never raises an alert.

The alert inbox

Alerts opens a single-page inbox with status cards across the top and a filter bar below them. You can narrow the list by date range, campaign, policy set, tag, and country; the four status cards (open, escalated, resolved, dismissed) double as the status filter — click one to show only those alerts, click it again to clear.

The cards count exactly the alerts the filters select, so the four of them always add up to the total shown under the table. Filtering to a single status makes that card's number match the total.

Each row shows the policy set that raised the alert and links to the related scan and campaign, with inline status actions so you can triage without leaving the list. Select multiple rows (or Select all) to change status in bulk — Select all covers exactly the alerts your current filters select, not the whole inbox.

Lifecycle

An alert moves through: open -> escalated (needs attention) -> resolved (handled) or dismissed (not actionable). The history is retained so you can audit how each was handled.

Notifications

To be told about alerts automatically, configure destinations under Account -> Alert Notifications — connect Slack via OAuth, claim a Telegram chat, or add an email destination. You can restrict delivery to selected statuses and act on alerts (resolve / dismiss / escalate) straight from the Slack or Telegram message.

Each campaign picks where its alerts go in its Notifications section, saved together with the rest of the campaign:

• Inherit — the organization's default destinations (those set to receive every inherit-mode campaign).
• Override — only the destinations you pick.
• Silence — no notifications from this campaign.

Route by label

A shared campaign can hold scans for several partners — for example direct-link checks for many DSPs, told apart by a scan label such as dspName. Turn on Route by label in the campaign's Notifications section and pick the label key; then give each partner destination a label rule (its Label routing, e.g. dspName is RichAds).

Each alert of that campaign goes to the inherit or override destinations that have no rule on the key, and to every destination whose rule matches the scan's value for the key — whether or not it is in the inherit or override list. Keys and values match regardless of case. A scan whose value no rule matches reaches only the destinations without a rule, so a partner never sees another partner's alerts. A rule only applies in campaigns that route by the same key.

The API sets the same routing with routing_label_key on PUT /api/v1/alert-notifications/campaigns/{id}/overrides, or in the notifications block of a campaign create / update request; each destination's rule is returned as route_label_key and route_label_values.