Skip to main content

Alerts and notifications

When the reputation feed pushes a new detection for one of your monitored domains, Umbra stores the exposure and raises an alert. This page covers where alerts land and how to route them.

Free plan

Free includes no alerts at all: no in-console notifications, no email, no Slack, no webhooks. The Alerts page is a locked upsell, and the bell shows a lock instead of a badge. Alerting starts on Pro. See Plans and billing.

The bell and the Alerts feed​

  • The bell in the header shows the unread count and the most recent items, with mark-all-read. The bell and the Alerts page always show the same unread count, and marking all read survives a reload.
  • Alerts in the sidebar's ENTITIES section is the full feed of new-exposure notifications.
  • Each alert says what it is about. On a verified domain: an Infostealer capture with the captured address (when it is readable) and the host it was stolen for, or a Breach record with the breach's name. On a domain you have not verified yet: how many new exposures arrived, and that verifying the domain shows which. Your own address is named even then, when the record is yours.
  • A burst is one row with a count, for example "424 new infostealer captures on example.com": consecutive records for the same domain and kind fold together.
  • Clicking an alert opens the identity when its address may be shown, otherwise the domain's Exposures filtered to records new in the last 30 days.

Org-wide routing: the Notifications page​

The Notifications page in the sidebar ACCOUNT section configures where events go, for the whole organization:

  • Rules, a matrix of event × channel grouped by category. Tick which events reach which channels. Events include new-exposure and critical-exposure detections, domain verifications, and team invites. A detection is critical when the feed's risk band for it is high or critical.
  • Channels, the destinations: Slack, webhook, and email. A default "Account email" channel pointing at the organization creator's address is seeded on signup, routed for every event.

Routing is org-wide, not per-user: one matrix describes how your organization is notified, and admins keep it in one place.

Grouped delivery​

Exposures arrive in bursts. One monitoring push can carry hundreds of new records for a single domain within a few minutes, and a message per record would bury the finding rather than report it. So email and Slack are grouped: for each burst your organization receives one summary, not one message per record. The subject line says what happened, for example "9 new exposures for example.com — 3 critical".

The summary is organized the way you would read it, by monitored domain, then by the breach or the service the credential was stolen from, with a severity band, the affected identity, and the exposed data for each record. Its headline counts are always the true totals, even when the listing itself is trimmed.

What grouping does not change:

  • The bell and the Alerts feed still show every record the moment it arrives. In-console alerting is immediate; a burst on one domain shows as one row with a count, and email and Slack are grouped into one summary.
  • Each alert's severity is the record's exposure score band: Very High is Critical, High is High, Medium is Medium, and Low or Very Low is Low. A record without a band reads as Medium.
  • A lone detection is never held back. Grouping waits on a burst, not on a clock: a single new exposure in a quiet week goes out within a couple of minutes.
  • Webhook channels still receive one payload per event, immediately, so automation on the other end keeps seeing one POST per record.
  • A channel ticked for both new exposures and critical exposures is now delivered to once, not twice.

Notification email never contains password data, not even the masked tail the console shows. It tells you what was found, where, and how bad; the credential detail stays behind sign-in in the console.

What reaches you where​

SurfaceWhat arrives
Bell + Alerts feedevery routed in-console event, the moment it arrives, with unread tracking
Email channelone grouped summary per burst, sent to the channel's address, with no password data
Slack channelthe same grouped summary, posted to the configured Slack destination
Webhook channelone payload per event, POSTed to your endpoint, for your own automation

The whole routing block is Pro-locked on Free. Free has no alerts, so there is nothing to route.